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

[Leslie Daigle <[e-mail]>]

[Vaguely suspecting you sent your message from a non-subscribed e-mail 
address, as this doesn't appear to have come through on the main mailing 
list.]

I don't see any issue with talking about re-ECN and re-Feedback, and 
being clear about the distinction, in the context of the BoF.  I'm not 
sure how much airtime we need/want to spend on comparing and contrasting 
them there, beyond ensuring that it is clear there is at least one 
reasonable to pursue in a WG.

In terms of supporting ECN deployment -- I'm not sure how much airtime 
that requires at the BoF, beyond possible discussion of whether it is a 
gating factor for viable progress, and whether there is a work item on 
an eventual charter.  Is that reasoanble?  However, I think it is 
important to make sure it remains a collateral point.

Leslie.

Matt Mathis wrote:
> So I have two issues that I would like to see addressed, I think as
> part of existing agenda items, but I want to be sure that they are not
> ruled out of order by the anti-rat hole police.
> 
> First, I really think we need to broaden Re-ECN to RE-Feedback, even
> under the still broader umbrella congestion exposure.  RE-ECN
> presupposes the deployment of ECN, which has not deployed in 10 years.
>  I believe that loss based RE-Feedback can provide much of the
> benefits of RE-ECN, but with a far easier deployment strategy.
> Furthermore unifying the semantics of the two approaches will make
> both stronger.
> 
> My point is really that we need to view loss based and ECN based RE feedback
> as equals, both likely to be present in steady state, and not one
> merely as a deployment strategy for the other.  Our terminology should
> reflect this.
> 
> Second, we need a task to actively promote ECN deployment.  Many
> people have have worked on this, and it has been all but vetoed by a
> couple of persistent problems.   Although shepherding deployment is
> not a traditional IETF activity, it really think it is the right venue
> to bring the right people to bear on the problem.   We need to divide
> the problem, such that improved technology in a couple of specific
> areas will help the broader community to help us to eliminate the tiny
> persistent problems that have thwarted ECN deployment.   I would
> really like to see the technological part done under ConEX.
> 
> (The required technology is to make OS releases that are targeted for
> technology users and beta testes run ECN black hole detection with
> automatic diagnosis and reporting.  As we get more experience with
> these algorithms and they get enabled for progressively wider pools of
> users we will gradually eliminate the bugs in the infrastructure).
> 
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis      http://staff.psc.edu/mathis
> Work:412.268.3319   Home/Cell:412.654.7529
> -------------------------------------------
> Evil is defined by mortals who think they know
> "The Truth" and use force to apply it to others.
> 
> 
> 
> On Tue, Oct 27, 2009 at 8:37 AM, Leslie Daigle <[e-mail]> wrote:
>> 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]
>> -------------------------------------------------------------------
>> _______________________________________________
>> re-ECN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/re-ecn
>>
> 

-- 

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