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

[<[e-mail]>]

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]>s.com>, Marcelo BAGNULO BRAUN
> ><[e-mail]>3m.es>, "MONCASTER, Toby" <[e-mail]>om>,
> >"Agarwal, Anil" <[e-mail]>om>, Tom Taylor
> ><[e-mail]>s.com>, 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