Re: [re-ECN] Revised agenda theory

[<[e-mail]>]

Some inline comments

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Leslie Daigle
> Sent: 25 October 2009 22:06
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: Matt MATHIS; [e-mail]
> Subject: Re: [re-ECN] Revised agenda theory
> 
> 
> Hi Bob,
> 
> I do take your point about viability (of mechanisms for congestion
> exposure, btw, not re-ECN specifically) being a challenge, but I also
> don't think we'll get to discussing chartering a working group if we
> don't take a whack at it.  "Focus" will be the watch-word.
> 
> I'm happy to discuss how to make sure that discussion _is_ focused.  I
> actually think your smiley-table (mail to Fred) is a reasonable
> starting
> point for at least some aspect of illustrating this.
> 
> I should also say -- I don't think the BoF can determine that
> congestion
> exposure is The One True Way to better Internet health.  I'm not even
> particularly convinced a WG can do that.  I'm hoping the bar is set at
> demonstrating that it is a useful and important step to pursue, even
as
> others are pursue elsewhere.

It may or may not be the One True Way, but as you say that is well
beyond the scope of a BoF or WG (maybe even beyond the IAB...)

> 
> A few more points, in-line:
> 
> Bob Briscoe wrote:
> > 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)
> 
> Which is pretty cool, but on the bof agenda might lead to some
> ratholing
> on whether we're just bashing TCP, no?

Definitely a rat hole (and we don't want to be Terriers pursuing rats in
this BoF).

> 
> >
> > 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).
> 
> I'm happy to have _a_ slide pointing out there's a lot of stuff going
> on
> in the world, because, as you note, it does communicate that this is
> getting broad airtime in the world at large.  But for the purpose of
> the
> BoF, I think the major emphasis should be on making sure the people in
> the room have enough information to determine whether they think there
> is an IETF activity here.
> 
> The latter is the theory behind "the problem" item on the agenda.  If
> there's a better way to handle that piece of it, happy to take
> sugestions.

I suspect the key here won't be convincing people that the IETF should
be doing work in this area. The bigger problem will be convincing them
that there is a small enough chunk of this huge problem space that the
IETF can do something sensible with it before the Internet becomes
extinct! So what is needed is very careful scoping. Yes, make it clear
that this is a problem that causes lots of people to go all gooey and
become too excited, but also impose strict limits on the scope to be
considered. 


> 
> And, I'll be sure to announce the ISOC activity here, when it's, errr,
> announced. :)
> 
> >
> > 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).

I'm not sure that is THE alternative. We need to be very careful not to
come across as scare-mongers, Nor to keep harping on about the evils of
flow-fairness. Those will just open up a line of ratholes to get stuck
in...

> >
> > ____
> > 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.
> 
> And, the sad reality is, we will not do it justice.  What we need to
do
> is hit the high points to illustrate that there is viability here, and
> it's worth chartering an IETF activity to delve into it in more depth.
> 
> One refinement to the agenda text occurs to me:
> 
> CONEX
>    5 mins  administrivia
>    5 mins  introduction by chairs
> Background
>   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]
> Discussion of potential IETF work
>   40 mins  discussion of viability of congestion exposure
>   20 mins  draft charter discussion
>   10 mins  questions and hums
> 

I like that refinement a lot... BUT to start that discussion we need a
slide with a very limited range of topics and a warning from the chairs
that the discussion can't get ratholed. The "discussion of viability..."
item needs to cover things like  "can we do congestion exposure?", "is
the IETF the right place to do this?", "Does re-ECn seem like a good
starting point?" and "How tightly should we limit any charter in this
area (what big items should be explicitly excluded from the charter)?"

Incidentally, strictly we have a 170 minute slot I believe (1520-1810
including the afternoon NON-snack break).

> 
> Leslie.
> 
> >
> >
> > 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
> 
> --
> 
> -------------------------------------------------------------------
> "Reality:
>       Yours to discover."
>                                  -- ThinkingCat
> Leslie Daigle
> [e-mail]
> -------------------------------------------------------------------
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn