Where to control [was Re: [e2e] TCP in outer space]

Cannara cannara at attglobal.net
Sat Apr 14 22:15:02 PDT 2001


Steven, I agree 100% and a number of folks have talked about application-level
control via network-level feedback, as you mention.

Alex


Steven Low wrote:
> 
> Alex
> 
> While I agree that routers should do more to help contorl congestion,
> I believe they should *not* determine source rate, as done
> in ABR Explicit Rate.   Rather, a router should figure out the right
> measure of congestion and feed back this information to sources that
> use this router.   A source, knowing the congestion information
> on its *path*, is in a better position to determine its rate.   A
> potential bonus of this approach is that
> sources with different valuation of bandwidth can adjust
> their rates differently even when the congestion on their paths is
> "identical".   For example, they can choose utility functions that
> are tailored to their applications, and use that to adjust their
> rates.   In summary, a router only knows how congested it is,
> and this is what it should inform the source about.   This is
> necessary and sufficient for a source to figure out its rate.
> 
> All these can be made precise, and it can be shown that
> this approach can be made optimal, stable, and robust as network
> scales up *arbitrarily* in delay, capacity and load.
> 
> Steven
> 
> > The point is that router/switch code can do far more these days than ever
> > imagined when the decision to offload performance and capacity decisions from
> > 'gateways' (routers) was made years ago.  The corollary is that this is not a
> > surprising reality.  So, for example, rather than simply using the hardware
> > RED capability now available to drop packets, use it to generate a more
> > intelligent control statement to the sender.  Source Quench and its original
> > purposes have been discussed, but consider that intelligent folks might even
> > go further -- let a little of this processor-cycle wealth be directed at the
> > network-layer without tricking the assumed transport, which is not the source
> > of all the traffic.  This is, of course being discussed.
> 
> __________________________________________________________________
> Steven Low, Assoc Prof of CS & EE
> slow at caltech.edu                        netlab.caltech.edu
> Tel: (626) 395-6767                     Caltech MC256-80
> Fax: (626) 792-4257                     Pasadena CA 91125



More information about the end2end-interest mailing list