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

[Bob Briscoe <[e-mail]>]

John,

I really like your list of principles. Where in the BoF do you 
suggest we put it?

And I agree with everything you've said in this email, with just a 
couple of inline comments...

At 13:36 26/10/2009, John Leslie wrote:
>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.)

As this sentence is in the passive, I assume you mean suppression by 
the transport or some other link than the congested one (not 
suppression by the congested link itself).

That's why we brought re-ECN to the IETF - because we had solved that 
problem. The draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt 
explains the mechanisms that can be built over re-ECN to detect & 
prevent suppression.

I've actually got a PhD thesis of proofs on this now, with pseudocode 
of the mechanisms, simulations etc etc, but I haven't got round to 
asking my company for permission to publish (mainly because they are 
more focused on sacking people than authorising publications at the 
mo). I promise it will be published soon.


>    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.

Have you been following Matt Mathis's work on Relentless TCP? And 
generally on TCP algos with window proportional to 1/p, rather than 
1/sqrt(p) like current TCP. The idea is these maintain the same 
number of loss or ECN signals per window however fast you go.

Is there some reason for choosing 8 or 9 orders of magnitude? I would 
have thought 1/p would scale indefinitely, but you may be thinking of 
other factors I've missed.

Scaling was also one of the main motivations for Kelly's primal algo. 
And it was one of my motivations for introducing re-ECN so we could 
shift from the TCP-friendly (1/sqrt(p)) track painlessly onto a 
scalable 1/p track without worrying about flow fairness.


Bob


>    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]>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design