[Iccrg] Congestion control definition and requirements of a new protocol

[Tim Shepard]

> > A. Definition of Congestion:
> > 
> > Network congestion is a state of degraded performance from the
> > perspective of a particular user.
>
>    This really won't do.
> 
>    We need to define something we can measure.
> 
>    And unless we measure something appreciably smaller than what a
> user will notice, there's no hope of controlling congestion very well.

The way I think about it, it is the standing queues.  And those are
measurable.  

I think if we get rid of the standing queues (by controlling
transmissions into the net, not by dropping packets until the
standing queue goes away), we will have accomplished the first half
of what we want to accomplish towards a new and improved congestion
control scheme.

(One scenario I like to keep in mind is a single TCP transmitting data
 over a path, with no other significant traffic in the net.  This
 single TCP will build a standing queue in front of the bottleneck,
 increasing delay (for itself, which probably does not matter, and for
 the other "insignificant" traffic, which might matter).)


The other half of what we want to accomplish would involve fairness,
the ability to do traffic engineering, et cetera.


> > 5. TCP fills up all available buffers at the bottleneck links, which
> >    results in long latency.?
> 
>    Better to say that TCP must inflate latency before generating the
> packet loss which will signal congestion. (It's not necessarily true
> that "all available buffers" are filled first.)

[....]

> > 7. TCP builds a standing queue at the point of congestion, which
> >    increases the delay. 
> 
>    This should be combined with #5. I'm not sure what words we should
> add to make this point clear.

Yes, with #7, #5 is redundant.  So perhaps we can delete #5 and just
have #7?

			-Tim Shepard
			 shep at alum.mit.edu