[Iccrg] RE: [tsv-area] Congestion Exposure (re-ECN): to BoF or to Bar BoF?

[philip.eardley]

Bob

I support this work. My views are that:

- work on Congestion Exposure (re-ECN) & TCP-unfriendly can proceed in
parallel - and in fact, given the time to get things done, the work
needs to be done in parallel. They're separate things - eg re-eCN
implies changes in network gateways, tcp-unfriendly could be useful in
some environments without re-ecn. (of course I'm not saying they're
completely independent - eg as you point out below their motivations are
connected.)
- on re-ecn, personally I don't see the benefit of waiting and would
prefer a BoF in Stockholm
- it would be good to see a proto-charter, or at least a list of
documents the WG would produce. Do you envisage the protocols being Expt
or Stds track? Is the output 1 protocol with similar scope to the
draft-briscoe-tsvwg-re-ecn-tcp, or are there more protocols? Plus what
other informational docs? - maybe some examples of how to use the
protocol - sort of an architecture doc?
- to me the point of the congestion exposure is that it's transparent in
2 senses: (1) it's visible to all network nodes (2) it's truthful. To
me, the reason re-ecn is very interesting is that it promises to give
both. I think both should be mentioned up front in any proto-charter as
what the objectives are.

Phil.

{ -----Original Message-----
{ From: tsv-area-bounces at ietf.org [mailto:tsv-area-bounces at ietf.org] On
{ Behalf Of Bob Briscoe
{ Sent: 21 May 2009 09:37
{ 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