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

[Leslie Daigle <[e-mail]>]

I like the principles a lot, too.

I'm thinking that could be an excellent jumping off point for 
"constraints", in the agenda.   Phil's currently slated to do that 
section.  Are you (John) going to be in Hiroshima?  And/or, can you work 
with Phil to integrate these points into the discussion-leading material?

Leslie.

Bob Briscoe wrote:
> 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

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------