Re: [re-ECN] FW: ConEx BoF announcement text

[" Ilpo Järvinen " <[e-mail]>]

On Thu, 22 Oct 2009, Fred Baker wrote:

> I'll argue something slightly different. It comes to the same endpoint, but
> through a different observation. Some of us, you Bob especially, are very
> familiar with this; others are perhaps less so. Bear with me.
> 
> Jain's 1994 patent on congestion control defines two terms: the "cliff" and
> the "knee" of a throughput curve.
> 
>           |
>       T   |      availabile capacity
>       h   | ---------------------------------------
>       r   |       +---+
>       u   |  knee/     \cliff
>       p   |     /       \
>       u   |    /         \
>       t   |   /           \
>           | /             \
>           |/               \
>           |/                 ----------------
>           -----------------------------------------
>                     Window  --->
> 
> As the TCP/SCTP window increases from zero to some value, throughput also
> increases. That stops when the available capacity has been consumed; at that
> point, even if the window grows, throughput does not. What increases instead
> is RTT, because a queue grows.

Up to this point I agree with this paragraph...

> If window continues to increase, at some point the queue starts dropping 
> traffic, and throughput degrades.

...However, this is not a true claim. As long as no unnecessary work is 
not done at any bottleneck (and we don't have a shared resource such as 
a wireless channel), thoughput does _not_ degrade (at all!), even though 
many keep asserting that without much of a thought nowadays. Of course 
non-infinitely long flows would introduce some anomalities to calculations 
through which one could use to show that this claim is "true" but I think 
that's hardly what people usually mean when they make that claim that 
dropping implies throughput degradation.

Somewhat related, for some reason there's a very common misconcept that 
drops imply poor performance. That is often stated as a fact without 
looking deeper into what really was the cause for sub-optimal 
performance, often that turns out to be something else when looked 
closely enough. I'd say that very often losses were, in fact, innocent.
Quite often the blame would fall on constant factor MD (if one is honest 
enough to admit).

Btw, your graph is not accurate (wrt. Jain), he's drawing a much sharper 
drop than you do at his "cliff" (so with ascii you'd have to use | at 
first to match him). I've some doubts about validity of that sharp 
angle too, so I find your graph is much more sensible (that is, as long as 
the resource is shared).

> By definition, the window at the "knee" is smaller than the window at 
> the "cliff", but throughput is the same.
> 
> Common TCP congestion control algorithms such as Reno and Cubic tune to the
> cliff. That has the upside of maximizing throughput; it has the downside that
> it is abusive to other applications such as voice/video (increased and
> variable RTT, and induces loss), and to other TCP sessions. #include
> <discussion of bittorent and why other users are negatively impacted by it>

I think Bob doesn't agree with you here, he isn't saying that congestion 
is something bad but something nearly opposite. Bob's own words:

"It would contradict this to say congestion is a problem - it's not - it's 
healthy and natural in a data network."

...It's just that if you keep doing that too much (beyond the congestion 
volume allocated for you), you would "suffer (if I've understood him 
right). ...So it has very little to do with operating in the "cliff" or 
"knee" in short timescales (unless of course you've already ran out of 
your quota).

> Other TCP congestion control algorithms based on ECN, CalTech FAST, etc, try
> to tune to the knee. This gets them exactly the same throughput including
> support of very high rate applications but with a smaller window value and
> therefore lower queue depth and lower probability of loss - both for
> themselves and their competitors. It does so without negatively, or at least
> AS negatively, impacting applications they compete with beyond seeking to
> share the available capacity with them.

I certainly agree with you here that low queuing delay is a desirable 
property too. ...However, I don't see how e.g., ECN alone could achieve 
low queue delay and high throughput at the same time, you'd need something 
more than that (mainly to remove the 0.5 factored MD). And after removing 
that, we'd get something close to what Matt Mathis is suggesting and that 
then does not anymore depend on ECN to work (though I think one could 
certainly avoid lots of loss recovering by signalling in early with 
ECN).

-- 
 i.