Subject: Re: [Diffserv] QOS, RSVP, Differential Services, Integrated Services and IPv6

From: [email-masked]
Date: Wed, 5 Apr 2000 08:11:53 EDT

In a message dated 4/5/00 8:04:10 AM Eastern Daylight Time, [email-masked] 
writes:

> At 02:10 PM 4/4/00 -0400, [email-masked] wrote:
>  >I have been thinking about guaranteeing latencies in packet delivery.
>  >If a WAN network provides transport for very large packets, and if a
>  >reservation is made for video traffic that requires a very low latency
>  >at high priority, would it not make sense for intermediate routers to
>  >fragment very large packets so that if a priority low latency packet
>  >arrived at an intermediate router while that router is transmitting
>  >a lower priority packet, the wait before the high priority low latency
>  >packet actually begins to transmit would be low because as soon
>  >as the reservation had been made, the router limited the transmit
>  >MTU size on the relevant interfaces to decrease possible delays
>  >through an intermediate router?
>  
>  In some cases, yes. On relatively low speed lines, some routers use PPP 
>  Multilink, even on a single line, in order to get the fragmentation and 
>  reassembly. VoIP data goes in the PPP IPCP stream, TCP data goes via the 
ML 
>  LCP.
>  
>  The place where this becomes unnecessary is when the speed of the link is 
>  fast enough that the jitter introduced by competing traffic is within 
>  acceptable bounds. That rate is on the order of megabits per second; for 
>  most equipment, T-1 links don't require this.

It depends on maximum packet sizes and the number of hops.  The
size of packets on some of the faster media have become quite
large, and supporting jumbograms has been rather common.  
Latencies can also accumulate.  With a sufficient number of hops
small delays can cause a lot of jitter.

Joachim Martillo
President
Telford Tools, Inc.
17 Pleasant Hill Ave.
Boston, MA 02126-2813
V 617-298-4107, 298-1617
F 617-298-1745
E [email-masked]
U http://www.telfordtools.com

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Fred Baker <[email-masked]>
Date: Wed, 05 Apr 2000 05:24:12 -0700

I think we're in violent agreement. At some relatively low speed, the PPP 
Multilink procedure can be used to fragment competing traffic. At some 
not-much-higher speed, it becomes irrelevant. We're dickering about the 
magic number.

---

From: David Charlap <[email-masked]>
Date: Wed, 05 Apr 2000 12:41:08 -0400

[email-masked] wrote:
>>> 
>>> I have been thinking about guaranteeing latencies in packet
>>> delivery.  If a WAN network provides transport for very large
>>> packets, and if a reservation is made for video traffic that
>>> requires a very low latency at high priority, would it not make
>>> sense for intermediate routers to fragment very large packets so
>>> that if a priority low latency packet arrived at an intermediate
>>> router while that router is transmitting a lower priority packet,
>>> the wait before the high priority low latency packet actually begins
>>> to transmit would be low because as soon as the reservation had been
>>> made, the router limited the transmit MTU size on the relevant
>>> interfaces to decrease possible delays through an intermediate
>>> router?
>>
>> In some cases, yes. On relatively low speed lines, some routers use
>> PPP Multilink, even on a single line, in order to get the
>> fragmentation and reassembly. VoIP data goes in the PPP IPCP stream,
>> TCP data goes via the ML LCP.
>>
>> The place where this becomes unnecessary is when the speed of the
>> link is fast enough that the jitter introduced by competing traffic
>> is within acceptable bounds. That rate is on the order of megabits
>> per second; for most equipment, T-1 links don't require this.
> 
> It depends on maximum packet sizes and the number of hops.  The size
> of packets on some of the faster media have become quite large, and
> supporting jumbograms has been rather common.  Latencies can also
> accumulate.  With a sufficient number of hops small delays can cause a
> lot of jitter.

Yes.  Let's take two examples here.  A 9K frame transmitted over Gigabit
ethernet (where 9K frames are commonly used) and a 1500-byte frame
transmitted over a T1 line.  If we ignore layer-1 and layer-2 bits and
use an approximation of the speed, we can get the approximate time it
takes to transmit a frame.  72us for the GigE frame (9KB = 72,000 bits
divided by 1,000,000,000 bits/s), and 8ms for the T1 frame (1500 bytes =
12,000 bits divided by 1,500,000 bits/s).

Neither of these delays are too bad.  Most apps can deal with even an
8ms delay.

But these delays may add up as the packet traverses many switches. 
Imagine a worst-case scenario where a low-latency packet goes through 30
switches and is queued for transmission just as a maximal-size packet
has begun transmitting.  This creates the maximal queuing delay -
generating the worst-case for jitter.

On the GigE network, the cumulative delay from being behind a 9K frame
at every hop is 2160us - or approximately 2.2ms.  This is probably
acceptible.  Especially when you consider that it's still significantly
less than the delay caused by one 1500 byte frame on the T1 network.

On the other hand, with the T1 switches, the cumulative delay from being
behind a 1500 byte frame at each hop becomes 240ms - nearly 1/4 second. 
This may well be unacceptible for some applications.

One possible solution (as was already proposed) is fragmentation to
smaller sizes.  Of course, this introduces other problems as well.

(Incidentally, this is one of the reasons why ATM can enforce delay and
jitter constraints over slow lines.  The segmentation and reassembly of
frames into cells reduces the transmission delay of a single cell down
to 283us over a T1 line, or 8.4ms over a worst-case 30-hop route.)

-- David