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