Subject: [re-ECN] Fwd: RE: Fwd: Pls bash: Congestion Exposure (re-ECN) BoF inHiroshima?

From: Bob Briscoe <[email-masked]>
Date: Mon, 07 Sep 2009 00:34:40 +0100

Folks,

I'm throwing in the towel tonight. I'll get up early manyana and try 
to get out a full draft of the BoF proposal before I get on a plane 
to Athens (middayish UTC Mon).

Any more comments on the draft structure below so far?

Following offlist comments, I'll probably be taking out the IETF 
Process part, which is more appropriate for charter discussions after 
the BoF, and less useful at the BoF itself.

Bob

>Date: Sat, 05 Sep 2009 13:31:14 +0100
>To: "Woundy, Richard" <[email-masked]>, 
>"COURCOUBETIS, Costas" <[email-masked]>, Steven BLAKE 
><[email-masked]>, Marcelo BAGNULO BRAUN 
><[email-masked]>, "MONCASTER, Toby" <[email-masked]>, 
>"Agarwal, Anil" <[email-masked]>, Tom Taylor 
><[email-masked]>, Ken Carlberg <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: RE: [re-ECN] Fwd: Pls bash: Congestion Exposure (re-ECN) 
>BoF inHiroshima?
>Cc: re-ECN unIETF list <[email-masked]>

[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

---

From: "Don Bowman" <[email-masked]>
Date: Mon, 7 Sep 2009 02:42:54 -0400

In the experiments (or focused work on deployment?) would suggest some
experimentation on interaction between WG and e.g. LEDBAT. Also for
experimentation the interaction between re-ecn and dynamic
bandwidth+spectrum allocation access such as wimax.
Also interaction of re-ecn w/ tunnels where there maybe congestion
signalled within the tunnel but not without, or vice versa.

In the motivation, suggest expanding on why accountability for
congestion is better for the end user. 

I think the draft structure is fine.

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 2009-09-07 1:35 AM
> To: Woundy, Richard; COURCOUBETIS, Costas; Steven BLAKE; Marcelo
> BAGNULO BRAUN; MONCASTER, Toby; Agarwal, Anil; Tom Taylor; Ken
> Carlberg; Leslie Daigle; Don Bowman
> Cc: re-ECN unIETF list
> Subject: Fwd: RE: [re-ECN] Fwd: Pls bash: Congestion Exposure (re-ECN)
> BoF inHiroshima?
> 
> Folks,
>

---

From: "Dirk Kutscher" <[email-masked]>
Date: Mon, 7 Sep 2009 09:49:38 +0200

Hi Bob,

The outline looks good. Maybe one comment:

For the proposal, it could be worthwhile to point out that there is a chance to do congestion accountability as a general Internet approach, not limited to a particular environment, which is why it should be done in IETF.

Having said that, I wonder whether we should look at some scenario-specific technical issues that might occur, e.g., when doing congestion accounting in mobile scenarios (where it could be of particular interest). This could also be a topic for the experiments and the focused work on deployments. Somebody else mentioned interactions with tunnels also.

Anyway, I think this should go forward and would be interested to support it.

Best regards,

Dirk

--
Dr. Dirk Kutscher
NEC Laboratories Europe

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: Monday, September 07, 2009 1:35 AM
To: Woundy, Richard; COURCOUBETIS, Costas; Steven BLAKE; Marcelo BAGNULO BRAUN; MONCASTER, Toby; Agarwal, Anil; Tom Taylor; Ken Carlberg; Leslie Daigle; BOWMAN Don
Cc: re-ECN unIETF list
Subject: [re-ECN] Fwd: RE: Fwd: Pls bash: Congestion Exposure (re-ECN) BoF inHiroshima?

Folks,

Bob

[snip]

Bob

_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 07 Sep 2009 23:10:16 +0100

Dirk,

Thanks. I've incorporated your comments...

...except the one about the general Internet - yes it would be 
interesting, but we have to show that we are being careful - any use 
of experimental values in the IP header has to be possible to unwind 
if the experiment proves unsuccessful. Hope that's reasonable.

Bob

At 08:49 07/09/2009, Dirk Kutscher wrote:
>For the proposal, it could be worthwhile to point out that there is 
>a chance to do congestion accountability as a general Internet 
>approach, not limited to a particular environment, which is why it 
>should be done in IETF.
>
>Having said that, I wonder whether we should look at some 
>scenario-specific technical issues that might occur, e.g., when 
>doing congestion accounting in mobile scenarios (where it could be 
>of particular interest). This could also be a topic for the 
>experiments and the focused work on deployments. Somebody else 
>mentioned interactions with tunnels also.
>
>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>London W3 6BL | Registered in England 2832014
>
>
>Carlberg; Leslie Daigle; BOWMAN Don
>Cc: re-ECN unIETF list

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 07 Sep 2009 23:15:00 +0100

Don,

>signalled within the tunnel but not without, or vice versa.

I've included all these merely as examples of what might be done - no 
need to commit to any at this stage.

>congestion is better for the end user.

Done - pls check it's OK

>I think the draft structure is fine.

I've end up including all the elements, but changing the order completely.

Bob