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

["Woundy, Richard" <[e-mail]>]

I have to agree with Toby's comments.
 
The charter should be a declarative document, e.g. "this is what we will do and how we will do it". We don't have to review the history of the process that led to the BoF/WG being set up. No one will care about that two years from now.
 
If you look at the first paragraph of the LEDBAT WG charter, it is a simple statement of the goal of the WG: "The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP."
 
If we want something similar, we could say: "This BoF xxx is focused on exposing information needed to share capacity among many users on the Internet. Specifically, the protocols to be considered by this BoF will expose the expected congestion on the rest of the end-to-end path visible in the IP header of each packet." (stealing Bob's words of course)
 
The charter should say briefly (one sentence) how other stakeholders benefit from re-ECN et al, particularly end users and application providers.
 
As for an alternative BoF title, why not use 'Congestion Transparency' or 'Congestion Exposure' for now? We can come up with a 'cute acronym' like contran or conexp later in the process.
 
-- Rich, heading back to my Labor Day holiday, http://en.wikipedia.org/wiki/Labor_day for those in the UK

________________________________

From: [e-mail] [mailto:[e-mail]]
Sent: Mon 9/7/2009 6:36 AM
To: [e-mail]; Woundy, Richard; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in Hiroshima?



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