Hi, I support this endeavor. I think it's a good idea.
Cheers, Michael >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Bob Briscoe >> > Sent: Thursday, May 21, 2009 10:37 AM >> > To: tsv-area IETF list >> > Cc: iccrg IRTF list >> > Subject: [tsv-area] Congestion Exposure (re-ECN): to BoF or >> > to Bar BoF? >> > >> > 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 > >
