Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in Hiroshima?

[Bob Briscoe <[e-mail]>]

Toby,

Good list.
inline...

At 09:52 08/09/2009, [e-mail] wrote:
>Having got a BoF proposal in (albeit a rather longer one than I
>expected) we can now turn our attention to the stuff that is needed to
>make the BoF a success:
>
>1) Decide what questions we will ask at the BoF in order to get clear
>hums that result in a WG being forms.
>2) Define EXACTLY the problem we are addressing (by writing a problem
>statement document). And keep this concise and focussed (e.g. only
>concentrate on a single aspect).
>3) Write a BRIEF email summarising the key points from the BoF proposal
>which can be used to publicise the BoF on a bunch of other lists.
>4) Find a couple of experienced people to chair this - ideally both
>having chaired successful BoFs and at least 1 having some experience in
>this space.
>5) Work out an agenda - I envisage at most 3 presentations - the
>problem, re-ECN as a potential solution (but without ANY protocol
>detail) and a summary of what the WG would do. Then work out who
>presents these.
>
>I'm sure there are other things I'm missing. Now we've got things moving
>let's keep the momentum going and hopefully we can have a successful BoF
>in November.

Extra stuff from an earlier draft agenda:
 > >    Demo (what demo?)
 > >    Misconceptions
 > >    Relationship to other w-gs
 > >    Community - who's doing what; who's planning what


Bob


>Toby
>
>
> > -----Original Message-----
> > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> > Sent: 08 September 2009 01:36
> > To: Moncaster,T,Toby,DER3 R
> > Cc: [e-mail]
> > Subject: RE: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> > Hiroshima?
> >
> > Toby, John,
> >
> > I picked up some of the ideas in this in time. But I didn't get to
> > the final parts of the thread until now (after I've posted for the
> > deadline).
> >
> > inline...
> >
> >
> > At 18:29 07/09/2009, [e-mail] wrote:
> > >Inline...
> > >
> > > > -----Original Message-----
> > > > From: John Leslie [mailto:[e-mail]]
> > > > Sent: 07 September 2009 17:41
> > > > To: Moncaster,T,Toby,DER3 R
> > > > Cc: [e-mail]; Briscoe,RJ,Bob,XVR9 BRISCORJ
> > R;
> > > > [e-mail]; [e-mail]; [e-mail];
> > > > [e-mail]; [e-mail];
> > >[e-mail];
> > > > [e-mail]; [e-mail]; [e-mail]
> > > > Subject: Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF
>in
> > > > Hiroshima?
> > > >
> > > > [e-mail] <[e-mail]> wrote:
> > > > >
> > > > > OK here is my attempt at something a bit better. Feel free to
> > bash
> > >it
> > > > > hard:
> > > > >
> > > > > -----------------
> > > > > Congestion Transparency
> > > >
> > > >    This doesn't feel like the correct title: we don't want
> > congestion
> > > > to be invisible, which is the direction this seems to aim. I'm
> > happier
> > > > with "Congestion Exposure".
> > >
> > >I guess I agree - I accept transparency is open to misinterpretation
> > by
> > >some people but it is technically a correct description - we are
> > making
> > >the level of congestion visible - in other words we are being
> > >transparent about it and not seeking to hide it...
> > >
> > >
> > > >
> > > > > It is increasingly clear that the current approach to sharing
> > > > capacity
> > > > > between users of networks isn't working.
> >
> > I kept my opening stating "The Internet is all about sharing
> > capacity...". I always think it's worth spelling out what makes the
> > Internet what it is - people get complacent and forget the basics are
> > important.
> >
> > Also, rather than making accusations that "it isn't working", I
> > preferred to say we're " realising we really don't understand." This
> > is lass accusatorial.
> >
> > >As a consequence ISPs feel
> > > > they
> > > > > have to police "heavy users" to free up resources for the bulk
>of
> > > > their
> > > > > customers. This involves making assumptions about the wishes of
> > >their
> > > > > customers which in turn is fuelling tension between ISPs,
> > customers,
> > > > > content providers and application writers.
> > > >
> >
> > I liked this opening. I put a much briefer sentence alluding to this
> > at the start, then returned to it a bit later.
> >
> >
> >
> > > >    Basically good. I wonder if there's a way to say something more
> > > > moderate than "fuelling tension". I'm partial to the term
> > "tussle"...
> > > >
> > >
> > >Yep, would be very happy with tussle, but we need to be clear that
> > this
> > >is not a healthy tussle (like Clark's Design of Tussle) - this is a
> > >tussle that cannot be won
> >
> > I called it an arms race.
> >
> >
> > > > > Other work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is
>looking
> > at
> > > > new
> > > > > approaches to controlling bulk data transfer rates. But these
>new
> > > > > approaches will only work with the cooperation of the operators.
> > > >
> > > >    This is not quite true: what we mean is that they will fail if
> > the
> > > > operators continue to punish congestion-free transport.
> > > >
> > > > > What is lacking is a mechanism to build trust between operators
> > and
> > > > > end-users and between different tiers of operators. In short the
> > > > > Internet lacks a system for accountability.
> > > >
> > > >    Good.
> >
> > Bu;;er - I missed this para of your mail - it's good. Hold it for
> > another time, Toby!
> >
> > > >
> > > > > This Congestion Transparency BoF focuses on exposing the
> > congestion
> > > > > information that end systems use to determine their
>transmission.
> > By
> > > > > sharing this information in an open manner among the many users
> > on
> > > > the
> > > >   ^^^^^^^
> > > >    Not quite right... I think we mean, "Openly propagating
> > congestion
> > > > information can provide..."
> > >
> > >Yes
> >
> > I wasn't sure about this. I prefer to avoid sentences like these that
> > muddy who is the subject of the verb. We should be clear that this is
> > hosts exposing congestion to networks. Truth in advertising.
> >
> >
> > > >
> > > > > Internet it can provide the foundations for trust and
> > accountability
> > > > > throughout the network. Specifically, the protocols to be
> > considered
> > > > by
> > > > > this BoF will expose the expected rest-of-path congestion in the
> > IP
> > > > > header of each packet such that nodes downstream of the source
> > can
> > > > see
> > > > > the impact that will be caused by any packet they forward.
> > > >
> > > >    Perhaps clearer to say "expose both actual congestion and
> > expected
> > > > rest-of-path congestion"...
> > >
> > >agreed
> >
> > Again, if I'd have noticed this, I'd have included it - sorry.
> >
> > I did manage to make the sentence I had much clearer tho.
> >
> >
> > > >
> > > > > Currently a protocol called re-ECN (re-inserted explicit
> > congestion
> > > > > notification) has been proposed to do this. Re-ECN is the
> > strongest
> > > > > candidate for adoption, but of course the proposed working group
> > is
> > > > > expected to redesign and thoroughly test alongside any
> > alternative
> > >if
> > > > > one surfaces.
> > > >
> > > >    Good, IMHO; but I'd end the paragraph there.
> > >
> > >I wasn't quite sure where to break the paragraphs - I kept changing
>my
> > >mind!
> > >
> > > >
> > > > > Whatever protocol is adopted, it should be possible for a
>network
> > > > > operator to count the volume of congestion that is attributable
> > > > > to an aggregate of traffic, as easily as it can count the volume
> > of
> > > > > bytes today. This can be done for each user, or for whole
> > attached
> > > > > networks. The defined protocol should work with minimal changes
> > to
> > > > the
> > > > > existing network, in particular it should work with unmodified
> > > > routers,
> > > > > but in the long run it is envisaged these small changes will
>make
> > a
> > > > big
> > > > > impact to how the limited resource of the network are shared.
> > > >
> > > >    I'd go for something more like, "The WG will publish a protocol
> > > > which
> > > > enables network operators to count the volume of congestion for
>any
> > > > chosen aggregate of traffic, whether per customer, per peer, or
>any
> > > > other aggregate."
> > >
> > >Sounds OK to me
> >
> > Again, I'd have used this, but what's there isn't so bad anyway.
> >
> >
> > > >
> > > >    And add, "The protocol should work with the substantial
>majority
> > of
> > > > existing routers needing no modification whatsoever."
> > >
> > >Yes
> >
> > I say "without changing forwarding on routers" (true if they already
> > implement RFC3168, which they should!)
> >
> > This nicely excludes the additions an ISP would add at trust
> > boundaries for policing etc.
> >
> >
> > > >
> > > > > This is not about changing the existing approach to congestion
> > > > control,
> > > > > where congestion is detected and responded to by transports on
> > > > endpoints
> > > > > (e.g. congestion control in TCP, RTP/RTCP). The only difference
> > is
> > > > that
> > > > > network operators will be able, if they choose, to monitor and
> > > > control
> > > > > the one factor that causes grief to their other customers: the
> > >volume
> > > > of
> > > > > congestion caused. In turn they can be monitored and controlled
> > by
> > > > their
> > > > > providers. The proposed working group will NOT mandate how
> > exposed
> > > > > congestion should be used. It will confine itself to the focused
> > >task
> > > > of
> > > > > defining the protocol for exposing congestion. However, it will
> > > > strongly
> > > > > encourage experiments into how this information can be used and
> > will
> > > > > ultimately produce guidance on the dos and don'ts of using this
> > > > > information.
> > > >
> > > >    Long-winded, but I'll let someone else edit it for length.
> > >
> > >Agree it needs to be reduced. May get round to it after my supper...
> >
> > I made it much shorter.
> >
> >
> > > >
> > > > > The proposed work items for this group are:
> > > > >
> > > > > 1) An informational document giving the motivations for
> > congestion
> > > > >    transparency and specifying the requirements for any protocol
> > > > >
> > > > > 2) An experimental protocol for congestion transparency. This
> > will
> > > > >    probably be based upon the proposed re-ECN protocol as
> > >significant
> > > > >    research work has already been done to understand and test
> > this
> > > > >    protocol.
> >
> > I avoided saying re-ECN again, as the main point had been made
>earlier.
> >
> > I added that we would define the protocol for v4, v6 & TCP
> >
> > Given we've already defined re-ECN for all these, I didn't think that
> > was committing us overly. (We haven't implemented for v6 tho - I
> > thought that would be a nice exercise for someone else).
> >
> > > >
> > > >    I'd say "likely" rather than "probably"; otherwise good.
> > >
> > >OK
> > >
> > > >
> > > > > 3) One or more informational documents reporting the results of
> > > > >    experiments on applications of the congestion transparency
> > > > >    protocol.
> > > >
> > > >    Good...
> > > >
> > > > >    Specifically these experiments are likely to look at means to
> > > > >    force honest disclosure of congestion information
> > > >
> > > >    I'm not thrilled with "means to force"... It implies ongoing
> > war.
> > > > I'd rather talk about "means to recognize misleading usage of
> > > > congestion-exposure bits", and that as part of Security
> > >Considerations.
> > >
> > >Indeed, but I was unsure how to put this - what the actual aim might
> > be
> > >be is to reduce the traffic to the equivalence of what it should be
> > for
> > >the declared congestion - in other words remove any gain from gaming
> > the
> > >system - so perhaps something like "means to prevent users gaining
> > from
> > >cheating or gaming the system"?
> >
> > I don't think it harms not to mention it's ungamable. If any passing
> > traveller turns up at the mic and says "can't they lie," it's a
> > useful excuse to introduce this whole area.
> >
> >
> > > >
> > > > >    and the impact of rationing the congestion volume a given
>user
> > or
> > > > >    network can cause.
> > > >
> > > >    I don't quite get the point here.
> > >
> > >OK, I was driving at what happens if you ration congestion on a per-
> > user
> > >basis. We have results that suggest this leads to heavy users having
> > to
> > >back of meaning lighter users that share a bottleneck will benefit
> > from
> > >being able to go faster (and that was with unmodified TCP CC)
> > >
> > > >
> > > > > The initial goal is that all the output of the working group
>will
> > be
> > > > > informational or experimental, but once the experiments have
>been
> > > > > completed then they will be used to determine if this approach
> > >should
> > > > > be standardised within the IETF.
> > > >
> > > >    Looks basically good! It might help to make reference to the
> > > > discussion
> > > > that has proceeded on this list...
> > >
> > >Yes, that is the missing bit- something that gives a feel for the
>size
> > >of this community (which seems to be getting quite large)
> >
> > I added a community size estimate in the covering note to the ADs,
> > rather than in the BoF proposal itself (where it's not so
>appropriate).
> >
> > Sorry again, for not getting to this thread before the deadline. But
> > I think some of it got in.
> >
> >
> > Bob
> >
> >
> > > >
> > > > --
> > > > John Leslie <[e-mail]>
> >
> > ________________________________________________________________
> > Bob Briscoe,               Networks Research Centre, BT Research

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research