[e2e] First rule of networking: don't make end-to-end promise s you can't keep.

[Ted Faber]

On Fri, Apr 23, 2004 at 07:45:19PM -0400, David P. Reed wrote:
> Cannara's basic idea occurs to many sophomores - that packet errors should 
> cause the source to send with a *larger* window (that's why he keeps saying 
> it is bad to "back off" when a packet is lost).  It's a strange idea that 
> is based on a theory that keeping the network buffers as full as possible 
> is a "good thing" for goodput - despite the fact that it pessimizes 
> end-to-end latency due to queueing delay, thus increasing the effective 
> delay through the control loop.   The end-to-end performance might go up if 
> you have errors but absolutely no congestion.  But if you have congestion, 
> too, you don't get much value out of filling up the congested path - the 
> path is already delivering all it can.

What you said is true, but I'd like to add another point.

IMHO, another compelling reason to behave conservatively here (slowing
down when a source infers congestion, and inferring congestion
conservatively) is that if an endpoint pours more data into a congested
network, every other user of that flow's bottleneck resouce faces
collapse with the abuser.  If people want to design systems that react
incorrectly to congestion and damage only their own throughput, I'm
amused at best, but basically uninterested.  Systems that are prone to
guessing wrong or behaving intemperately and disrupting the service of
well-behaved users get my attention.

Congestion control design is largely about building a system that
aggressively uses resources on behalf of of an individual source while
keeping the system as a whole in a safe and productive state.  When the
information one is using to operate such a system is necessarily
incomplete, outdated, or both, it behooves one to proceed conservatively.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040423/d4613b8f/attachment.bin