[re-ECN] Fwd: Congestion Exposure (re-ECN): to BoF or to Bar BoF?

[Bob Briscoe <[e-mail]>]

Folks,

This list has been dead for a while. This note is just to notify 
folks that I've started the discussion below. To continue the 
discussion, please do so on [e-mail] .

Cheers


Bob

>Date: Thu, 21 May 2009 09:37:07 +0100
>To: "tsv-area IETF list" <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: Congestion Exposure (re-ECN): to BoF or to Bar BoF?
>Cc: "iccrg IRTF list" <[e-mail]>
>
>TSV Area folks,
>
>[Please continue this discussion on tsvarea]
>
>I'd like to launch a concrete protocol-specification activity on 
>congestion exposure (with re-ECN as a candidate solution) in 
>Stockholm? Here at the ICCRG in Tokyo, we've just agreed that this 
>doesn't conflict with the new IRTF ICCRG  design team in this space 
>or prejudge any consensus on direction (see background below). The 
>question is purely about timing...
>
>I'm finding that re-ECN seems to feature somewhere in the plans of 
>those expressing an opinion in the ICCRG discussions. My concern: 
>the protocol that will take longest needs to be finished soonest. 
>E.g. ECN took 7 years from first research paper to proposed standard.
>
>Therefore, I'd like to propose we get started on a specific protocol 
>specification activity, in parallel to the ICCRG design team. We 
>have to set this up so it doesn't imply it is the *official and 
>only* way forward. But it's a good punt to be starting on.
>
>My questions are:
>* Do you think discussions should start on building a BoF on 
>"Congestion Exposure" in Stockholm (getting late but still do-able)?
>* Or less ambitiously should we arrange another ad hoc BoF (bar BoF) 
>in Stockholm, building on ICCRG work in Tokyo this week, to get a 
>community together to form a BoF later?
>* Or do people actively oppose anyone doing anything yet on 
>congestion exposure or re-ECN in the IETF or IRTF?
>
>Background on TCP-unfriendly and on re-ECN
>-------------------------------------------
>You may be aware that, in San Francisco we had discussions in 
>TSVArea (prompted by Matt Mathis's talk) on whether to move beyond 
>TCP-friendliness as a comprehensive direction for both sharing 
>Internet capacity and future congestion controls. In the IRTF ICCRG 
>the same week it was decided to set up a design team to work on the 
>way forward and propose it in an informational RFC - Matt Mathis has 
>kicked off a first shot <draft-mathis-iccrg-unfriendly-00.txt>. We 
>just had the launch meeting of that design team at the ICCRG here in Tokyo.
>
>Re-ECN is a change to IP to make congestion as transparent to the 
>network as it is to the endpoints (hence congestion exposure). Then:
>i) causes of excessive congestion can be kept in check if ISPs 
>choose - but at the bulk packet level like the Internet architecture 
>should be - agnostic to behaviour of individual flows;
>ii) and ISPs that under-provision can be held to account as well.
>(see the end for the status of re-ECN).
>
>Re-ECN status
>-------------
>We've been keeping a draft spinning on this proposed change to IP 
>since 2005. It's still an individual contribution waiting for the right time.
><draft-briscoe-tsvwg-re-ecn-tcp-07>
><draft-briscoe-tsvwg-re-ecn-tcp-motivation-00>
>
>When we first presented it and had subsequent ad hoc BoFs, the idea 
>fell on stony ground. I think because back then few could see the 
>limitations of TCP-friendly. Even if you still think there's 
>something in TCP-friendly, it was apparent from the lack of any hum 
>it received in SF that we at least need something wider.
>
>It seems re-ECN is one of those things people want someone else to 
>have already done. It gives a permit to be able to work on protocols 
>that are really safe and fair, but they're not strictly TCP-friendly 
>(e.g. mTCP, relentless, etc). For instance, re-ECN would allow ISPs 
>to count how little congestion LEDBAT traffic was causing, so they 
>need not count it against the user's allowance, etc.
>
>We've now implemented it. There's now a great amount of security 
>analysis on trying to game it and attack it and how it defends 
>itself. People are working on using it as a basis for other DDoS 
>protection mechanisms. Another is trying to build traffic 
>engineering over it. Others are interested in deploying it using 
>proxies. It's potential impact on net neutrality etc is being 
>analysed by regulatory and economics people. So has it's time come?
>
>Cheers
>
>
>Bob
>
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research