Re: [re-ECN] Revised agenda theory

[Bob Briscoe <[e-mail]>]

Leslie,

This looks good, but see below about the viability item, wherein lie 
monsters. Also, a couple of thoughts before that:

1/ I've been thinking... We should add an item to the many purposes list:
- evolution path beyond TCP (running out of dynamic range)

2/ I think it would be cool to have a brief session on the community 
around this; what people are doing in this space, why, etc. This 
could be structured:
- either as one of the chairs reporting all this (requiring people to 
have told you in advance what they're doing - plus scraping the list 
archive for what people said when they introduced their interest recently),
- or as a vox pop.

It would also be a chance to report on some of the activity that has 
been going on to ensure the commercial & public policy community 
would be happy with such a change to the Internet (e.g. the GIIC 
thing you went to, and any ISOC activities you're planning).

3/ On the "discussion of viability" it occurs to me that the BoF 
can't really discuss how viable it might be to deploy re-ECN without 
also considering the viability of alternative approaches to solve 
each of the problems we claim to be able to solve (or even whether 
alternatives exist).

How otherwise are we going to
- side-step the net neutrality problem?
- simplify inter-domain e2e QoS?
- move beyond TCP which is running out of dynamic range?
- and so on?

Taking evolution beyond TCP as an example...

In the IRTF ICCRG, Matt Mathis has proposed that moving to 1/p 
congestion controls (rather than 1/sqrt(p) like TCP) would allow 
congestion control to scale indefinitely, by maintaining a high 
congestion information rate as flow rates & link rates scale. Whereas 
if we stick with TCP-friendly, the information rate per window is 
already becoming stupidly low (hours between loss signals) as rates 
increase over the next few years. To put it bluntly, as carriers 
deploy more capacity, we'll be held back by the e2e protocols, which 
aren't able to use it.

Widespread re-ECN deployment would allow us to relax the TCP-friendly 
requirement, so we can bless 1/p controls and shift onto a sounder 
evolution path.

The alternative seems to be changing every router (and every LSR and 
every ethernet switch) in the Internet to do RCP (which still aims 
for flow-rate-fairness so it still drives ISPs into net neutrality 
issues, yada yada).

____
Do you see my point about trying to talk about the viability of 
re-ECN in isolation from wider debate on the viability of the 
alternatives? But such a session would require a lot of cluefulness 
in the audience to understand it. You might recall the p2pi workshop, 
which covered just a small part of this space. It was a selected set 
of participants, but even then the cluefulness factor from each 
specialist about a each related area was painfully low.

I'm not saying we shouldn't try to talk about viability, but it will 
be a complicated session to do justice to the debate.


Bob

At 04:03 24/10/2009, Leslie Daigle wrote:

>Hi,
>
>We need to get an agenda posted.  Subject to suggested changes, 
>and/or absent howls of dissent, we'll post the following. Note that 
>I have expanded it to allow more discussion of the specific 
>viability of the approach.
>
>We'll work on framing up some discussion for that part of the agenda 
>during the next week, or so.
>
>Leslie.
>
>
>
>Congestion Exposure (ConEx) is a proposed new IETF activity to enable
>congestion to be exposed along the forwarding path of the Internet. By
>revealing expected congestion in the IP header of every packet,
>congestion exposure provides a generic network capability which allows
>greater freedom over how capacity is shared. Such information could be
>used for many purposes, including congestion policing, accountability
>and inter-domain SLAs. It may also open new approaches to QoS and
>traffic engineering.
>
>The purpose of the BoF is to explore the support for and viability of
>pursuing an IETF activity to define a basic protocol to expose the
>expected rest-of-path congestion in the IP header. Any such protocol
>should work with minimal changes to the existing network, in particular
>it should work with unmodified routers. There is already one existing
>proposal that builds on ECN to provide rest-of-path congestion
>information in every IP header and other proposals may come forward.
>
>More detail is available at:
>http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
>
>BoF Co-Chairs:
>
>Leslie Daigle <[e-mail]>
>Philip Eardley <[e-mail]>
>
>
>Agenda
>
>  5 mins  administrivia
>  5 mins  introduction by chairs
>40 mins  the problem
>             context/motivation [Rich Woundy]
>             technical problem [Mark Handley]
>10 mins  constraints  [Philip Eardley]
>30 mins  towards a solution
>             overview of re-ECN   [Bob Briscoe]
>40 mins  discussion of viability
>20 mins  draft charter discussion
>10 mins  questions and hums
>
>
>N.B.:  This assumes our current 160min agenda space (check my 
>math!). If the BoF moves, we'll have to re-think.
>
>
>--
>
>-------------------------------------------------------------------
>"Reality:
>      Yours to discover."
>                                 -- ThinkingCat
>Leslie Daigle
>[e-mail]
>-------------------------------------------------------------------
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design