[e2e] Question about propagation and queuing delays

[David Hagel]

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?

- 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.
>