[e2e] Question about propagation and queuing delays

[David Hagel]

>From all that I hear, access links seem like the main curlpits that
cause most of the congestion today. But so many of the current
congestion control evaluations focus on alleviating congestion in the
network core. Perhaps a simpler network model, in which only access
links can be the bottlenecks, might yield much simpler congestion
control solutions? Has there been any work in this direction? With all
the non-TCP applications (like VoIP) emerging on the horizon, does
relying on TCP alone for congestion control make much sense?

(List moderators -- in case I am stirring some old soup of discussion
on this list, please feel free to kill this thread. I am new to this
list.)

- Dave

On 8/23/05, Filipe Abrantes <fla at inescporto.pt> wrote:
> 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
>