The MPLS WG Archive

[raymond zhang <zhangr@info.net>]

Curtis,

Thanks for the response and see some further comments in line...   Based 
upon discussions we have thus far including your response to my comments in 
response to Uzelac's email, maybe I should make some clarifications first 
which may help my understanding of your input as well in any further 
discussions:

The environment in which I am referring to is a global IP/MPLS packet-based 
network spanning all major and sub-continents where it is not always 
possible to get ample bandwidth (over-provisioning) economically (very 
expensive in fact)...  The issues of delay or packet loss do not normally 
present problems at all as you pointed out, in some continental or national 
networks of ISPs or SPs but to offer similar level of integrated services 
(voice/data) for customers with world-wide locations, it is in these remote 
regions and over last mile local loops that we spend a bit more efforts on 
to optimize.

On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is 
needed.  I think we both agree on that.  As for PE doing the comp/depcomp, 
I'd like to hear a bit more from the Vendors...  My experience has been 
that hardware based compression at PE levels on the edge of the network 
with large # of aggregating diffserve-enabled customer links presents 
complexity that may become unmanageable to SPs and with amount of edge 
features already processed through hardware, would adding 
compression/decompression be even feasible ?  Besides,   the upgrade 
path  may be very costly for these line cards which maybe deployed in large 
numbers across the global network as we add new feature sets/hardware 
capabilities.  So I am not in favor of it as an option for PE level 
routers.   Therefore the concept of distributing compression/decompression 
into CE levels, not in the network appeals in a great deal.  If PE is not 
doing the comp/decomp, then the compressed path needs to be e2e...

Further comments in lines ....

Regards,
Raymond

At 11:01 AM 2/20/2003 -0500, Curtis Villamizar wrote:

>Raymond,
>
>I trimmed out part of your response.
>
>In message <5.1.0.14.0.20030219124931.024f2be8@delta.info.net>, raymond 
>zhang w
>rites:
> >
> > Good point...my brief description above is not the best example to
> > illustrate this.  However issue remains in such situations.  Upper bounds
> > in terms of delay and loss need to be maintained in a much stricter sense
> > for such real-time class as voice...  Also, as Bur and Jerry pointed 
> out, a
> > payload size of 20 to 30 bytes enables us to do that much better across 
> the
> > voice path in delay budget planning  in terms of queue efficiency (per HoP
> > delay and variance), esp across the lower speed local-access links at 
> lower
> > sub-T1/E1 rates in an integrated data/voice environment.  It may be more
> > pronounced when the voice path spans across multiple continents with low
> > speed last mile connections.
>
>Tiny payload is needed for queue efficiency is a myth left over from
>the ATM days.  It is simply not true.

I think there are two aspects in this...  Firstly traffic flows with 
constant packet size would improve queue efficiency (M/D/1) and smaller 
packet payload would reduce delay across low speed links (not an issue once 
again in areas of network with large pipes since no or little qeueuing) 
which is required as part of the budge delay planning.  The voice quality 
is provided on a per path basis not just over segments of the path inside 
SP's major portion of the backbone.   ( I don't mean to spur another around 
of discussions on ATM vs. IP at all ! I thought issues are well understood 
by now).

>Lose overhead and queues are smaller.  Do some delay variation
>buffering and jitter is a total non-issue.
>
>This is like the IP vs ATM discussions of the mid-1990s.
>
> > >If you had large payloads the same link would hold 120-150 calls
> > >depending on how large the payload was.
> >
> > You meant muxing voice frames from multiple calls into one packet ?  Now I
> > understand a bit what you are referring to, altho not all customer
> > locations have same number of concurrent calls, many remote locations with
> > very small # of concurrent calls.  That means we would either have voice
> > packets with variable frame-sizes on EF queues or stuff more voice frames
> > from the same call into one packet ?
>
>No I meant increasing payload to 200 bytes to decrease overhead so
>that there was 50% more payload capacity on the same link.

So if not muxing voice frames from multiple calls between same pair of GWs, 
would then stuff more voice frames of the same call into the RTP payload 
?   If CE is the gateway (oftentimes it is in today environment), then as 
mentioned before larger packet payload would present delay issues in 
queuing/serialization over low speed local loops.  I don't think PE is the 
right place to do that this.

> > >The way things have been explained to me is an attempt is made to keep
> > >no more than about 30% of the bandwidth on a link for EF (or pick a
> > >number) and leave the rest for IP.  The actual EF reservation might be
> > >40% to 70% of the link so if you went to 101 calls and only 100 fit,
> > >IP would be squeezed out of some more bandwidth than you'd like it to.
> >
> > A larger EF allocation on an egress interface may starve the rest of the
> > data queues... That's why there is upper bound for EF allocation.  Of
> > course, the higher the link speed, the higher EF bandwidth can be 
> allocated
> > (e.g. local-access link).  In addition, EF traffic is policed which will
> > not erode into bandwidth space allocated for other classes.
>
>This is what the ISPs are doing.  TCP is compressible and some 95-98%
>of Internet traffic is TCP, much of it large enough flows to compress
>in the event of congestion.
>
>This is what ISPs are doing.  They could favor SLA traffic over
>non-SLA traffic (at least one way) but it hasn't become a practical
>problem for most ISPs to the point where they've bothered to do so.
>
>For the most part backbone links are sufficiently overprovisioned to
>absorb the variation in traffic load without special queueing except
>for the EF service.  Some of the aggregation links (regional) might be
>a little more problematic for some SPs.



>The statement that EF traffic is policed in this case is for the most
>part not accurate.


But it is, at least over the CE-PE link.

>SPs would like the VOIP gear to have limits on
>calls going out but most (all?) don't.  Failing that SPs would like to
>be able to use policing but it is impractical.  Ideally, VOIP would
>use LSPs with different EXP and setup/resv priority with a bandwidth
>allocation that

But on the edge (CE-PE links) and inside network, voice traffic is treated 
via strict priority over other types of traffic which would begin to starve 
other classes of traffic should its resource occupation exceeds a threshold 
(varies with link speed)...  You would need CAC on this which there is not 
one over a MPLS/IP packet backbone...  TE LSP only signals the reservation, 
not CACing.

>  reflected the traffic volume being offered.

Right... We have to understand the per-class (traffic type) traffic mix in 
the network for primary path placements planning.  But it is somewhat 
difficult when over-provisioning is not a good option in some areas of the 
networks and during node/link events.

>Currently, the only practical way to get the bandwidth allocation
>right or close to right is either configured based on history (usually
>close to right, but some argue maybe not close enough) or based on
>filtered measurements (and the filters may need some work here).
>Measuring the bandwidth allows the LSPs to be rerouted but does not
>handle the case were the bandwidth is no where to be found and the
>VOIP equipment needs to block calls.  So far the practical answer has
>been to ignore that case and ask VOIP gear for a configured limit on
>calls.
>
>There is some work on adaptive bandwidth techniques were the payload
>itself is changed (lower bandwidth encoding) when congestion is
>detected (some level of loss occurs).  An interesting change that any
>VOIP gear could make without any changes to standards would be to move
>the playout point ahead in time by 10-50 msec as congestion is
>detected.  In the absense of congestion, you'd have tiny packets and
>as small a delay as practical.  On the onset of congestion, you'd have
>small loss and a switch from 30 msec to 40 msec playout delay.  The
>improvement for G.709 would be from 30/(30+40) to 40/(40+40) percent
>of the bandwidth being used for payload (43% to 50%).  You would
>immediately get 16+% more capacity for a 10 msec additional delay.  If
>congestion persists, you can push this all the way to 80 msec, and get
>55% more traffic over the same link.  If you could also just compress
>the RTP and UDP headers (yielding 24 byte overhead rather than 40),
>this could become quite viable (55-76% payload for 30-80 msec).  If
>the network becomes congested, it certainly makes more sense to relax
>the delay criteria than to introduce loss.
>
>Curtis