Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in Hiroshima?

[Bob Briscoe <[e-mail]>]

Guys,

OK, I've just got to your comments saying it 
needs to be a lot more punchy and shorter - will 
have a go in the minimal time left.

I've just realised I've got 90mins, not 30 (I was accounting for summer time).

I'll have big carve up with the scissors and add lashings of snake-oil :)


Bob

At 12:11 07/09/2009, João Taveira Araújo wrote:
>Agree with most of Toby's comments, and would 
>add that the last 3 paragraphs seem too long to basically convey:
>
>- LEDBAT shows that there is a need for more 
>flexible CC paradigms than TCP-friendliness
>- LEDBAT itself is only a solution to a subset 
>of problems, and we need an overarching framework to:
>   - expose congestion so operators are no 
> longer prone to information assymetry.
>   - allow different CC algorithms to evolve 
> independently within less restrictive design space than TCP-friendliness.
>
>Joao
>
>[e-mail] wrote:
>>Immediate top-level comment - drop the re-ECN from the title. This is a
>>BoF where we are trying to get the IETF to agree there is a need to
>>introduce congestion transparency. Re-ECN is a specific protocol for
>>doing that but there may be others so we shouldn't put it in the title.
>>
>>I really fear the overall order of things is wrong as well. The bulk of
>>the first 3 paragraphs is just about IETF processes and the IRTF... The
>>first paragraph is fine but you need to expand on that and get quickly
>>towards a summary of the problem (the IETF hasn't provided a proper
>>system on which to build network accountability so ISPs have started to
>>bodge their own, with dire consequences for the future of the network).
>>
>>I think we need to re-phrase quite a bit of the detailed stuff as well,
>>but that is a matter of editing rather than complete change of meaning
>>so I will leave it for now...
>>
>>Final thing - this is already starting to get too long. The MPTCP BoF
>>description was ~600 words in total, TANA 9pre-cursor to LEDBAT) was
>>~450 total). You are already at 750 and you have 3 major bullets with no
>>text! In other words we need to cut by about 50%...
>>
>>Toby
>>
>>
>>>-----Original Message-----
>>>From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
>>>Sent: 07 September 2009 11:19
>>>To: Woundy, Richard; COURCOUBETIS, Costas; Steven BLAKE; Marcelo
>>>BAGNULO BRAUN; Moncaster,T,Toby,DER3 R; Agarwal, Anil; Tom Taylor; Ken
>>>Carlberg; Leslie Daigle; BOWMAN Don
>>>Cc: re-ECN unIETF list
>>>Subject: Fwd: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
>>>Hiroshima?
>>>
>>>Folks,
>>>
>>>Attached is my attempt so far. I started again - I'm happy with it so
>>>far, but it needs the specifics added at the end, where indicated.
>>>
>>>I'm sending in case I don't get good connectivity while travelling.
>>>Once I'm done, I'll send a complete copy. But this gives something for
>>>you to push back on or for you to propose alternative text.
>>>
>>>Apologies for sending an attachment (in a hurry).
>>>
>>>
>>>Bob
>>>
>>>
>>>
>>>>Date: Sat, 05 Sep 2009 13:31:14 +0100
>>>>To: "Woundy, Richard" <[e-mail]>om>,
>>>>"COURCOUBETIS, Costas" <[e-mail]>gr>, Steven BLAKE
>>>><[e-mail]>menetworks.com>, Marcelo BAGNULO BRAUN
>>>><[e-mail]>[e-mail]>, "MONCASTER, Toby" <[e-mail]>om>,
>>>>"Agarwal, Anil" <[e-mail]>om>, Tom Taylor
>>>><[e-mail]>[e-mail]>, Ken Carlberg <[e-mail]>
>>>>From: Bob Briscoe <[e-mail]>
>>>>Subject: RE: [re-ECN] Fwd: Pls bash: Congestion Exposure (re-ECN) BoF
>>>>inHiroshima?
>>>>Cc: re-ECN unIETF list <[e-mail]>
>>>>
>>>[snip]
>>>
>>>
>>>>I'm off to a wedding for the rest of the day. I'll get back to this
>>>>first-thing (UK time) Sunday.
>>>>
>>>>Here's a suggested proposal outline:
>>>>I'm aiming for something as brief as possible (e.g. 1-2pp).
>>>>
>>>>1. Intro
>>>>   1 para top level motivation: Accountability for Congestion
>>>>   1 para ambitious, so we have to bite off smallest self-contained
>>>>
>>>chunk
>>>
>>>>   1 para which particular bites to take (using an expt approach like
>>>>
>>>LISP):
>>>
>>>>     a) (INF) recording motivation(s)
>>>>     b) (EXP) base congestion exposure protocol
>>>>     c) (STD) process pre-requisites to do (b)
>>>>     d) (INF) reports on experiments
>>>>   1 para where other stuff is getting done, e.g. ICCRG
>>>>
>>>>2. A little more on each proposed working-group activity
>>>>2.1 Motivation
>>>>     Accountability for Congestion
>>>>     Good fences make good neighbours
>>>>     - IETF not been good at doing this (NATs, firewalls)
>>>>     - this is a chance to do it well
>>>>     Vision
>>>>     - ECN gives all traffic tiny jitter & loss
>>>>     - congestion accountability handles other QoS dimension; b/w
>>>>
>>>allocation
>>>
>>>>     - that's QoS sorted :)
>>>>2.2 Protocol work
>>>>        prob re-ECN, but open to suggestions
>>>>        IPv4, IPv6 & TCP as example transport (for now)
>>>>2.3 IETF Process
>>>>     Depends on protocol encoding chosen
>>>>     Current view:
>>>>       need bit 48 in IPv4 hdr & IPv6 extension hdr + clash with ECN
>>>>
>>>nonce
>>>
>>>>     Planned assignment of required field(s) as experimental
>>>>     Guidelines on how to confine experimental values (in space &
>>>>
>>>time)
>>>
>>>>2.4 Reports on Experiments
>>>>     This w-g NOT designed to standardise uses of the protocol
>>>>     - e.g. policers, new congestion controls, simpler QoS,
>>>>       inter-domain metering, traffic engineering, DDoS miitigation
>>>>     But w-g will act as a focus for expts & trials in using its
>>>>
>>>protocol
>>>
>>>>     Will produce reports on role of congestion exposure in trials,
>>>>
>>>issues,
>>>
>>>>     recommendations, re-thinks, etc.
>>>>     Informs any future move from experimental to stds track
>>>>2.5 (Optional) Focused work on deployment?
>>>>     This is more than the minimum work that the w-g needs to bite
>>>>
>>off
>>
>>>>     But it's the most important gating factor
>>>>     Therefore, it could form a focused piece of work in its own
>>>>
>>right
>>
>>>>     Survey of middleboxes that will break ECN, re-ECN etc.
>>>>     Permanent partial deployment (user & net choice to expose
>>>>
>>>congestion)
>>>
>>>>     Incremental deployment outline & incentives
>>>>
>>>>3. Proposed BoF Agenda
>>>>    Motivations (which main motivation?)
>>>>    Demo (what demo?)
>>>>    Misconceptions
>>>>     - congestion (with ECN) != impairment
>>>>     - uncongested path != good (a symptom of broken transport
>>>>
>>>protocols)
>>>
>>>>     - exposing congestion != operator privacy concerns
>>>>    Brief protocol outline
>>>>    Relationship to other w-gs
>>>>    Community - who's doing what; who's planning what
>>>>    Questions to put to a vote
>>>>
>>>>
>>>>Bob
>>>>
>>>
>>>Bob
>>>
>>>
>>>________________________________________________________________
>>>Bob Briscoe,               Networks Research Centre, BT Research
>>>
>>_______________________________________________
>>re-ECN mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/re-ecn
>>
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research