[re-ECN] TCP's "Dynamic Range"

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> wrote:
> At 22:06 25/10/2009, Leslie Daigle wrote:
>>Bob Briscoe wrote:
>>> 
>>> I've been thinking... We should add an item to the many purposes list:
>>> 
>>> - evolution path beyond TCP (running out of dynamic range)
>>
>> Which is pretty cool, but on the bof agenda might lead to some 
>> ratholing on whether we're just bashing TCP, no?
> 
> [BB] Not at all. Everyone in the transport area knows TCP has run out 
> of dynamic range. It's a well-known problem.

   I've been thinking somewhat along this line, though I wasn't using
the term "dynamic range", but rather considering signal-to-noise in
our feedback function.

   Beyond any question, TCP has been successful at curing "congestion
collapse" -- which is, after all, what it aimed to do.

   But packet loss, as a feedback signal, is frankly terribly unsuited
to fine-tuning how to share bandwidth at the bottlenecks. It's not,
IMHO, "bashing" TCP to point out this difference.

   Network operators, at best, can only estimate packet loss, not
measure it meaningfully, and even if they could measure it with 100%
accuracy, they'd have no hope of relating packet loss to the backoff
it signals.

   That's because the multiplicative decrease it signals is based
on end-to-end flows at a higher layer. We're looking at five or more
orders of magnitude difference in the amount of backoff signaled by
a packet lost. For a network operator, the signal is quite lost in
the noise!

   As we review the history of TCP, we notice that attempts to move
away from packet loss have failed to dependably avoid congestion
collapse: thus implementations tend to depend entirely on packet
loss to signal backoff; and other congestion-notification tends to
be ignored or even suppressed.

   (BTW, that's an issue we need to be prepared to discuss: how can
re-ecn operate when ECN marks are suppressed? Even though most of
the suppression history concerns ICMP, there will be folks who think
ECN will suffer similar suppression.)

   We should recognize that multiplicative-decrease on packet loss
is a proven winner for avoiding congestion collapse, and concentrate
on what's a better signal for management of bottleneck bandwidth.
I propose a few principles:

1) The signal needs to be visible to the network manager managing
   the bottleneck;

2) The signal should be distinct enough to be the basis for cost
   allocation for upgrading the bottleneck;

3) The signal should be visible to end-systems, giving a decent
   measure of how much to backoff their sending rate;

4) The signal should enable "backpressure" to allow network managers
   to avoid forwarding too many packets towards the bottleneck;

5) The signal should not involve packet loss.

   I believe that a properly-designed signalling system can work
for at least eight or nine orders of magnitude of sender bandwidth.
To be complete, a proposal should probably get into how many bits
per signal, but I'm personally convinced that re-ecn can work
beyond five orders of magnitude.

   So, avoiding the bits-per-signal question, are the five principles
above sufficient? Are they necessary? Can we come up with a good
presentation of such principles for the BoF?

--
John Leslie <[e-mail]>