[e2e] TCP un-friendly congestion control

[Steven Berson]

On Fri, 6 Jun 2003, David P. Reed wrote:

> Congestion loss rates are hardly small!!!
> 
> Little's theorem suggests that congestion loss rates can and do grow quite 
> large quite rapidly as arrival rate approaches service rate.

Just a quick nit - this is not a very good characterization of
Little's Theorem.  Little's theorem talks about the relationship
between the number in a system, the throughtput, and the time in
system.  You are implicitly assuming that time in system increases
rapidly as arrivial rate approaches service rate, but that depends on
additional charateristics of the arrival process and the service
process.

> What you may wish to say is that congestion loss rate variation is too 
> small in the control region around the desirable operating point, where 
> congestion loss = 0 and throughput = maximum.
> 
> But ultimately the problem remains with this research that trying to 
> optimize the system to operate at 100% capacity on the bottleneck link(s) 
> is the wrong way to run a network.
> 
> Instead of running such a network, increase the capacity of the bottleneck 
> links to 10x load!  It's cheaper and the customers are happier.

I don't think you have made a convincing economic argument here.

Regards,
Steve
 
> At 04:25 PM 6/6/2003 -0400, J. Noel Chiappa wrote:
> >     > From: "dave o'leary" <doleary at juniper.net>
> >
> >     > For more information:
> >     > http://netlab.caltech.edu/FAST/
> >     > http://netlab.caltech.edu/pub/papers/fast-030401.pdf
> >
> >Thanks for the pointers; in looking over the material there, I came across a
> >point which I'm wondering about, and I'm hoping someone here can enlighten me.
> >
> >
> >I've always heard that at extremely high speeds packet-loss based congestion
> >feedback (Reno) had problems in practise, because since you can't
> >differentiate between i) packet losses caused by congestion, and ii) losses
> >caused by errors, then if you have a roughly constant BER then as the link
> >speed goes up, you start getting a faster rate of 'false' (i.e. error-caused,
> >not congestion-caused) loss signals, which cause unneeded (and undesirable)
> >reductions in sending speed. I assumed that queueing-delay based congestion
> >feedback (Vegas) would avoid this issue.
> >
> >This point is not made in detail in the papers, although there is a brief
> >comment which allude to this whole area - "Reno .. must maintain an
> >exceedingly small loss probability in equilibrium that is difficult to
> >reliably use for control".
> >
> >I am informed that this comment also refers to the difficulty of using as a
> >control signal something (the congestion loss rate) which is small and
> >difficult to estimate reliably; not only that, but as the paper points out,
> >the quantization of that signal is large compared to the signal amplitude,
> >making for even more trouble.
> >
> >
> >So now I finally get to my question!
> >
> >I would suspect that in practise, the first aspect I mentioned (two different
> >kinds of loss signal getting mixed up) is probably an even bigger problem
> >than the other one (the difficulty of using such a small signal for
> >feedback).
> >
> >Does anyone have sany information on this, either from real-life measurements,
> >or simulations?
> >
> >         Noel
>