[e2e] Congestion control and avoidance - QoS?

[David P. Reed]

The idea of implementing improved congestion control on an end-to-end, 
cooperative basis in a new protocol (replacing TCP as the basis for HTTP) 
sounds like a worthy goal.

But it would be helpful before embarking on it to get an upper bound on the 
level of benefit to the network that one could hope to achieve.

If the inherent demands on the network (traffic and latency) are such that 
congestion will happen anyway, better to find a way to link congestion to a 
funding source that will build out capacity sufficient to reduce congestion.

If the inherent demands are low enough that a new algorithm will reduce 
latency variability in a way that people are willing to pay for, then the 
trick is to tie latency improvements to ROI.

I suspect that in places where we see congestion, the first condition 
holds, so a quicker route to profiting from reducing latency variability is 
coordination the financing of build-out - to do it in the right 
places.  Creating a capacity futures market would fix this much more quickly.

More likely, though, most latency variability is edge-based (either in 
servers or the first mile access network), and in either case the network 
is not the primary problem.


At 02:33 PM 8/17/2001 +0100, Panos GEVROS wrote:

>Michael Welzl typed :
>
>  |Or maybe it would be implemented in Windows and "make the Internet
>  |faster". That might even work. Hmmm ... which makes me think:
>  |Could Microsoft actually "make the Internet faster" for us all
>  |by implementing some new and clever congestion control mechanism?
>
>Michael,
>
>actually the place to look is the web servers
>as most of the traffic originates *from* them to the periphery
>also many of them run open source OSs and modifications would be easier
>
>Panos

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html