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

[<[e-mail]>]

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.

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