[e2e] Question about propagation and queuing delays

Filipe Abrantes fla at inescporto.pt
Tue Aug 23 09:35:40 PDT 2005


Hello David,

David Hagel wrote:
> Thanks, this is interesting. I asked the same question on nanog and
> got similar responses: that queuing delay is negligible on todays
> backbone networks compared to other fixed delay components
> (propagation, store-and-forward, transmission etc). Response on nanog 
> seems to indicate that queuing delay is almost irrelevant today.
> 
> This may sound like a naive question. But if queuing delays are so
> insignificant in comparison to other fixed delay components then what
> does it say about the usefulness of all the extensive techniques for
> queue management and congestion control (including TCP congestion
> control, RED and so forth) in the context of today's backbone
> networks? Any thoughts? Are the congestion control researchers out of
> touch with reality?
> 

The latencies mentioned by David Reed are in the case of a 
non-congestioned path, and how it was already referred here, nowadays 
the most common case is to have our access link (xDSL/cable...) at 
home/office to be the bottleneck (the ping would struggle to fill the 
link right?). So, to get an approximate value for the maximum queueing 
delays you should try a ping when you have background traffic that fully 
utilizes your access link.

Congestion Control only plays an active role when there is a bottleneck 
in the path... (well not totally true as the guys from the 
high-bandwidth delay and lossy paths may tell you).

As to queue management, one of it's goals is also to promote fairness 
between flows (TCP is not that good at it), so i can see some usefulness 
in them too. If the final result is actually good enough I still don't 
know (I havent' gone too deep into this issue).

I just did a ping to my home which is on a 2Mb-dl/128kbit-ul cable 
connection from work (where I am) to exemplify this. At home I started a 
P2P program which had the upload capped at 6KByte/s (capped by the 
application, so there could be instantaneous overloads i think) I got this:
(the upload link was the bottleneck as my download was well below the dl 
limit)

$ ping xxxxxxxx.no-ip.org
PING xxxxxxx.no-ip.org (83.132.76.xx) 56(84) bytes of data.
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=1 
ttl=52 time=71.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=2 
ttl=52 time=109 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=3 
ttl=52 time=88.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=4 
ttl=52 time=29.5 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=5 
ttl=52 time=399 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=6 
ttl=52 time=307 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=7 
ttl=52 time=131 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=8 
ttl=52 time=78.6 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=9 
ttl=52 time=87.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=10 
ttl=52 time=54.2 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=11 
ttl=52 time=93.7 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=12 
ttl=52 time=22.4 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=13 
ttl=52 time=21.8 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=14 
ttl=52 time=45.2 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=16 
ttl=52 time=251 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=17 
ttl=52 time=22.1 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=18 
ttl=52 time=297 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=19 
ttl=52 time=290 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=20 
ttl=52 time=280 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=21 
ttl=52 time=21.0 ms

--- xxxxxxxx.no-ip.org ping statistics ---
21 packets transmitted, 20 received, 4% packet loss, time 20020ms
rtt min/avg/max/mdev = 21.046/135.229/399.044/117.287 ms


Then I capped the upload at 3Kbyte/s and got this:

$ ping xxxxxxxx.no-ip.org
PING xxxxxxx.no-ip.org (83.132.76.xx) 56(84) bytes of data.
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=1 
ttl=52 time=22.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=2 
ttl=52 time=22.2 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=3 
ttl=52 time=88.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=4 
ttl=52 time=34.3 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=5 
ttl=52 time=23.3 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=6 
ttl=52 time=24.6 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=7 
ttl=52 time=25.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=8 
ttl=52 time=22.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=9 
ttl=52 time=20.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=10 
ttl=52 time=52.5 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=11 
ttl=52 time=21.4 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=12 
ttl=52 time=30.9 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=13 
ttl=52 time=21.4 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=14 
ttl=52 time=42.8 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=15 
ttl=52 time=20.5 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=16 
ttl=52 time=22.0 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=17 
ttl=52 time=24.7 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=18 
ttl=52 time=24.4 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=19 
ttl=52 time=21.3 ms
64 bytes from a83-132-76-xx.cpe.netcabo.pt (83.132.76.xx): icmp_seq=20 
ttl=52 time=20.6 ms

--- xxxxxxxx.no-ip.org ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19018ms
rtt min/avg/max/mdev = 20.593/29.482/88.992/15.843 ms


As you can see, queueing delays are noticeable.

Best Regards

Filipe Abrantes


> - Dave
> 
> 
> On 8/21/05, David P. Reed <dpreed at reed.com> wrote:
> 
>>I can repeatably easily measure 40 msec. coast-to-coast (Boston-LA), of
>>which around 25 msec. is accounted for by speed of light in fiber (which
>>is 2/3 of speed of light in vacuum, *299,792,458 m s^-1 *, because the
>>refractive index of fiber is approximately 1.5 or 3/2).   So assume 2e8
>>m/s as the speed of light in fiber,  1.6e3 m/mile, and you get 1.25e5
>>mi/sec.
>>
>>The remaining 15 msec. can be accounted for by the fiber path not being
>>straight line, or by various "buffering delays" (which include queueing
>>delays, and scheduling delays in the case where frames are scheduled
>>periodically and you have to wait for the next frame time to launch your
>>frame).
>>
>>Craig Partridge and I have debated (offline) what the breakdown might
>>actually turn out to be (he thinks the total buffering delay is only 2-3
>>msec., I think it's more like 10-12), and it would be quite interesting
>>to get more details, but that would involve delving into the actual
>>equipment deployed and its operating modes.
>>
> 
> 

-- 
Filipe Lameiro Abrantes
INESC Porto
Campus da FEUP
Rua Dr. Roberto Frias, 378
4200-465 Porto
Portugal

Phone: +351 22 209 4266
E-mail: fla at inescporto.pt


More information about the end2end-interest mailing list