The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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.

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.

> >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.  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 reflected the traffic volume being offered.
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