[e2e] Queue size of routers

[Bruce]

even if one says i can have a delay*bw queue

1. is the queue length determinisitic in the present scenario? site a being
closer that site B etc is still possible, isnt it?
2. if not, the only people who know its not happening are the "end points"
of the session

also, buffering is fine, but the only purpose the buffer serves is when one
oversubscribes the bandwidth

so making "desired bandwidth"=available bandwidth is still a better
option........

yes, if the buffer was a caching buffer etc, it would make more sense to do
the idea suggested.....

let us assume i remove flow control from the host side

what we then have is:
1. hosts pumping out data as they feel, the network has to sustain the same
2. packets lost, no one has no idea why..i simply ask for a retrasmit and do
away with sliding window.
3. a good way to look at 2 in todays scenarios is that "packets lots are
really lost...not delayed"
4. dont adjust the window size....simply set a larger MTU per request and
syn-ack each frame, not a "window" this implies i send more data per
frame....and i need to ensure all the paths in the route support it. but one
still needs to see if the "frame got there" to make the upper layers work



 -Bruce
----- Original Message -----
From: Joerg Micheel <joerg at nlanr.net>
To: Michael Welzl <michael.welzl at uibk.ac.at>
Cc: <end2end-interest at postel.org>
Sent: Saturday, January 18, 2003 3:45 AM
Subject: Re: [e2e] Queue size of routers


> Gentlemen,
>
> On Fri, Jan 17, 2003 at 08:55:07PM +0100, Michael Welzl wrote:
> > 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?
>
> My understanding of this configuration is that the maximum RTT any
> packet could incur is 2*minRTT for a given path. This is such that
> TCPs at the host have a way to decide when a packet surely must have
> been lost (by timing it out accordingly).
>
> Obviously, realtime UDP-based applications might require a different
> behaviour, but most of the Internet thus far has been optimised to
> carry TCP traffic, which still accounts for the bulk of the data.
>
> Joerg
> --
> Joerg B. Micheel Email: <joerg at nlanr.net>
> NLANR MNA at SDSC/UCSD Page:  <joerg at vodafone.net.nz>
> The University of Waikato, CompScience Phone: +64 7 8384794
> Private Bag 3105 Fax:   +64 7 8585095
> Hamilton, New Zealand Plan:  PMA, TINE and the DAG's
>