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

[Bob Briscoe]

Dimitri,

I've cc'd to the iccrg, because it's a v good question that others on 
the list might want answered.

The discussions in Tokyo concluded that the ICCRG itself is mainly 
focused on congestion control protocols and there is less of an 
appetite for traffic security, policing etc. Therefore the ICCRG is a 
natural home for new congestion controls that might arise if 
congestion exposure existed, but not the best home to do the 
congestion exposure work itself.

Traffic security expertise is a fairly rare resource in the IETF/IRTF 
and it was thought they wouldn't feel ICCRG was their natural home.

Also, the proposal is for standards track, rather than IRTF activity 
on this particular aspect. This is because the research that has 
already been done has identified a piece that can safely and 
separately be standardised without committing to any particular 
transport behaviour that might be added on top.


Bob

At 11:00 23/05/2009, PAPADIMITRIOU Dimitri wrote:
>Bob:
>
>Why did you exlcude the possibility to progress the work in the ICCRG
>context ?
>
>Did you discuss this option/alternative in the context of the ICCRG
>meeting held in Tokyo ?
>
>thanks,
>-dimitri.
>
> > -----Original Message-----
> > From: tsv-area-bounces at ietf.org
> > [mailto:tsv-area-bounces at ietf.org] 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