AW: [e2e] Queue size of routers

[Raghurama 'REDDY']

Here is my understanding -

BW*Delay is an end-2-end layer-3 concept (for example in TCP) that need
to have that much buffering, primarily in the end hosts, in order to do
"reliable" transport.

Buffering in backbone routers is necessary for a different reason.  They
may have multiple igress and multiple egress interfaces.  At any point
in time it is possible to have:

	sum(input-rates) > capacity of the output link

So backbone routers also need buffering.  Even though this does not
explcitily have anything to do with BW*Delay product, it has to be
proportional to BW in order to proive buffering for a certain length of
time.

Regards,

--rr

From:	SMTP%"michael.welzl at uibk.ac.at"  "Michael Welzl" 17-JAN-2003 15:26:44.85
To:	minshall at acm.org, avg at kotovnik.com
CC:	end2end-interest at postel.org
Subj:	AW: [e2e] Queue size of routers 

> -----Ursprungliche Nachricht-----
> Von: end2end-interest-admin at postel.org
> [mailto:end2end-interest-admin at postel.org]Im Auftrag von Greg Minshall
> Gesendet: Freitag, 17. Janner 2003 18:38
> An: Vadim Antonov
> Cc: end2end-interest at postel.org
> Betreff: Re: [e2e] Queue size of routers 
> 
> 
> > Routers in real backbones have the delay*bw of buffer space.
> 
> good!

Why?

I'm serious - I know that a delay*bw queue length is just
right if, for example, you suddenly fill the capacity of a
dumbbell bottleneck in a simulation with new flows and
don't want some of the initial packets to be dropped,
thereby eliminating a potential traffic phase effect. But
is that a good choice for a backbone router?
The LA<->Tokyo RTT is quite a bit of delay ... is that
really reasonable when only a small number of flows may
show this RTT? Shouldn't backbone routers be more concerned
with traffic aggregates instead?

And: is there RED in backbone routers?

Cheers,
Michael