Re: [re-ECN] Revised agenda theory

[Bob Briscoe <[e-mail]>]

Leslie,

At 22:06 25/10/2009, Leslie Daigle wrote:

>Hi Bob,
>
>I do take your point about viability (of mechanisms for congestion 
>exposure, btw, not re-ECN specifically) being a challenge, but I 
>also don't think we'll get to discussing chartering a working group 
>if we don't take a whack at it.  "Focus" will be the watch-word.

[BB] Currently it looks like an open discussion session. Is that the 
intention? If so, a recipe for 'lack of focus'!


>I'm happy to discuss how to make sure that discussion _is_ 
>focused.  I actually think your smiley-table (mail to Fred) is a 
>reasonable starting point for at least some aspect of illustrating this.

[BB] Yes - that would work well.

We (the MIT CFP working group on interconnection & traffic 
management) are doing a white paper that draws of roadmap of the 
space. Once it's sufficiently coherent (soon) I'll post a draft. It 
may help structure this debate a little.


>I should also say -- I don't think the BoF can determine that 
>congestion exposure is The One True Way to better Internet 
>health.  I'm not even particularly convinced a WG can do that.  I'm 
>hoping the bar is set at demonstrating that it is a useful and 
>important step to pursue, even as others are pursue elsewhere.

[BB] Exactly.
I see the question the BoF is answering as
* "Will the IETF allow these guys a space to experiment?"

I see the question a w-g would answer as
* "Has there been sufficient verification and interest in this 
approach to move from experiment to stds track?"

BTW, 'space' in the first bullet means both space in terms of agenda 
time and potentially header space, but the precise header space at 
issue will be raised late once the w-g has deliberated


>A few more points, in-line:
>
>Bob Briscoe wrote:
>>Leslie,
>>This looks good, but see below about the viability item, wherein 
>>lie monsters. Also, a couple of thoughts before that:
>>1/ 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 suggested adding this point, because the alternatives in this space 
seem totally impractical (e.g. upgrading every router at once).


>>2/ I think it would be cool to have a brief session on the 
>>community around this; what people are doing in this space, why, 
>>etc. This could be structured:
>>- either as one of the chairs reporting all this (requiring people 
>>to have told you in advance what they're doing - plus scraping the 
>>list archive for what people said when they introduced their 
>>interest recently),
>>- or as a vox pop.
>>It would also be a chance to report on some of the activity that 
>>has been going on to ensure the commercial & public policy 
>>community would be happy with such a change to the Internet (e.g. 
>>the GIIC thing you went to, and any ISOC activities you're planning).
>
>I'm happy to have _a_ slide pointing out there's a lot of stuff 
>going on in the world, because, as you note, it does communicate 
>that this is getting broad airtime in the world at large.  But for 
>the purpose of the BoF, I think the major emphasis should be on 
>making sure the people in the room have enough information to 
>determine whether they think there is an IETF activity here.
>
>The latter is the theory behind "the problem" item on the 
>agenda.  If there's a better way to handle that piece of it, happy 
>to take sugestions.
>
>And, I'll be sure to announce the ISOC activity here, when it's, 
>errr, announced. :)

[BB] And report on GIIC?


>>3/ On the "discussion of viability" it occurs to me that the BoF 
>>can't really discuss how viable it might be to deploy re-ECN 
>>without also considering the viability of alternative approaches to 
>>solve each of the problems we claim to be able to solve (or even 
>>whether alternatives exist).
>>How otherwise are we going to
>>- side-step the net neutrality problem?
>>- simplify inter-domain e2e QoS?
>>- move beyond TCP which is running out of dynamic range?
>>- and so on?
>>Taking evolution beyond TCP as an example...
>>In the IRTF ICCRG, Matt Mathis has proposed that moving to 1/p 
>>congestion controls (rather than 1/sqrt(p) like TCP) would allow 
>>congestion control to scale indefinitely, by maintaining a high 
>>congestion information rate as flow rates & link rates scale. 
>>Whereas if we stick with TCP-friendly, the information rate per 
>>window is already becoming stupidly low (hours between loss 
>>signals) as rates increase over the next few years. To put it 
>>bluntly, as carriers deploy more capacity, we'll be held back by 
>>the e2e protocols, which aren't able to use it.
>>Widespread re-ECN deployment would allow us to relax the 
>>TCP-friendly requirement, so we can bless 1/p controls and shift 
>>onto a sounder evolution path.
>>The alternative seems to be changing every router (and every LSR 
>>and every ethernet switch) in the Internet to do RCP (which still 
>>aims for flow-rate-fairness so it still drives ISPs into net 
>>neutrality issues, yada yada).
>>____
>>Do you see my point about trying to talk about the viability of 
>>re-ECN in isolation from wider debate on the viability of the 
>>alternatives? But such a session would require a lot of cluefulness 
>>in the audience to understand it. You might recall the p2pi 
>>workshop, which covered just a small part of this space. It was a 
>>selected set of participants, but even then the cluefulness factor 
>>from each specialist about a each related area was painfully low.
>>I'm not saying we shouldn't try to talk about viability, but it 
>>will be a complicated session to do justice to the debate.
>
>And, the sad reality is, we will not do it justice.  What we need to 
>do is hit the high points to illustrate that there is viability 
>here, and it's worth chartering an IETF activity to delve into it in 
>more depth.
>
>One refinement to the agenda text occurs to me:
>
>CONEX
>   5 mins  administrivia
>   5 mins  introduction by chairs
>Background
>  40 mins  the problem
>              context/motivation [Rich Woundy]
>              technical problem [Mark Handley]
>  10 mins  constraints  [Philip Eardley]
>  30 mins  towards a solution
>              overview of re-ECN   [Bob Briscoe]
>Discussion of potential IETF work
>  40 mins  discussion of viability of congestion exposure
>  20 mins  draft charter discussion
>  10 mins  questions and hums

[BB] Yup - fine.
Except, would feasibility be a more precise word than viability?

Cheers

Bob



>Leslie.
>
>>
>>Bob
>>At 04:03 24/10/2009, Leslie Daigle wrote:
>>
>>>Hi,
>>>
>>>We need to get an agenda posted.  Subject to suggested changes, 
>>>and/or absent howls of dissent, we'll post the following. Note 
>>>that I have expanded it to allow more discussion of the specific 
>>>viability of the approach.
>>>
>>>We'll work on framing up some discussion for that part of the 
>>>agenda during the next week, or so.
>>>
>>>Leslie.
>>>
>>>
>>>
>>>Congestion Exposure (ConEx) is a proposed new IETF activity to enable
>>>congestion to be exposed along the forwarding path of the Internet. By
>>>revealing expected congestion in the IP header of every packet,
>>>congestion exposure provides a generic network capability which allows
>>>greater freedom over how capacity is shared. Such information could be
>>>used for many purposes, including congestion policing, accountability
>>>and inter-domain SLAs. It may also open new approaches to QoS and
>>>traffic engineering.
>>>
>>>The purpose of the BoF is to explore the support for and viability of
>>>pursuing an IETF activity to define a basic protocol to expose the
>>>expected rest-of-path congestion in the IP header. Any such protocol
>>>should work with minimal changes to the existing network, in particular
>>>it should work with unmodified routers. There is already one existing
>>>proposal that builds on ECN to provide rest-of-path congestion
>>>information in every IP header and other proposals may come forward.
>>>
>>>More detail is available at:
>>>http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
>>>
>>>BoF Co-Chairs:
>>>
>>>Leslie Daigle <[e-mail]>
>>>Philip Eardley <[e-mail]>
>>>
>>>
>>>Agenda
>>>
>>>  5 mins  administrivia
>>>  5 mins  introduction by chairs
>>>40 mins  the problem
>>>             context/motivation [Rich Woundy]
>>>             technical problem [Mark Handley]
>>>10 mins  constraints  [Philip Eardley]
>>>30 mins  towards a solution
>>>             overview of re-ECN   [Bob Briscoe]
>>>40 mins  discussion of viability
>>>20 mins  draft charter discussion
>>>10 mins  questions and hums
>>>
>>>
>>>N.B.:  This assumes our current 160min agenda space (check my 
>>>math!). If the BoF moves, we'll have to re-think.
>>>
>>>
>>>--
>>>
>>>-------------------------------------------------------------------
>>>"Reality:
>>>      Yours to discover."
>>>                                 -- ThinkingCat
>>>Leslie Daigle
>>>[e-mail]
>>>-------------------------------------------------------------------
>>>_______________________________________________
>>>re-ECN mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/re-ecn
>>________________________________________________________________
>>Bob Briscoe,                                BT Innovate & Design
>
>--
>
>-------------------------------------------------------------------
>"Reality:
>      Yours to discover."
>                                 -- ThinkingCat
>Leslie Daigle
>[e-mail]
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design