Cell Relay Archive

[Paul Koning <pkoning@xedia.com>]

Hal Murray wrote:
> 
> > Delay and bandwidth in a network are independent parameters.
> > It is possible to have low delay with low bandwidth or high
> > bandwidth, and high delay with low bandwidth or high bandwidth.
> 
> I've lost the question that started this thread, but I think
> it would be easy to jump to the wrong conclusion if you started
> with that paragraph.
> 
> Delay has several sources.
> 
>   One is speed of light.  It takes longer to send a packet
>   10 miles than to send it 1 mile, assuming the same link
>   technology.
> 
>   Another is bandwidth times message length.  It takes longer
>   to send a packet over a 10 megabit link than it does over
>   a 100 megabit link.  (Assuming same link length and similar
>   adapter performance and things like that.)

True.  But the definition of "delay" most commonly used in
measuring network devices is "first bit in to first bit out"
(or, if you like, "last bit in to last bit out").

By that definition, the clock rate of the interfaces is eliminated
from the picture (unless you're mixing link speeds).  That's why
that definition is used.

>   Another is processing time for the CPU to check routing tables
>   and the driver to check status and fill in the control blocks.
> 
> Another important source of delay is the time spent on a queue.
> 
> For a given traffic level, the queueing delay will be lower
> on a faster link.

Not necessarily.  For a given queue length, yes.  But queue 
lengths vary in a non-obvious way if you change link speed.
(Raj Jain has some nice examples of this, illustrating that
the often used approach "throw more bandwidth at it" isn't
necessarily a solution to congestion and may in fact make
matters worse.)

> For a given link, the queueing delay will be longer if there
> is more traffic using a larger fraction of the link bandwidth.

Again, not necessarily.  If you have ineffective congestion
control, perhaps.  If you have good congestion control, you
can run at close to link speed without having queues build up.

The definition of perfect congestion control is a scheme that
maintains the queue length at 1, not counting "packets in
flight" in the case of a link that has ARQ.  In that case,
the delay is independent of load (which is why it's perfect
congestion control).  Practical schemes can come fairly close
to this.

> Adding capacity (increasing link speed) doesn't change the
> speed of light.  It might (accidently) change the processing
> delay if you have to upgrade your router (faster CPU) to handle
> the faster line.  It will change the bandwidth*length delay
> if you upgrade the bandwidth of a single link.  It won't if
> you add a parallel link of the same bandwidth.

As I said, some of these things don't necessarily reduce delay.

I suppose I did overstate things a bit to make a point.
There's a common perception that delay is inversely proportional
to throughput.  That's clearly wrong.  My statement is perhaps
overstating things but I believe it is closer to the truth.
(Another example along the same lines is "conformance and
interoperability are independent properties".  I think both
originate with Bill Hawe, then at DEC network architecture, 
by the way.)

An accurate statement would be "there is in many cases a modest amount
of correlation between increased bandwidth and reduced latency".

	paul
-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: pkoning@xedia.com
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859