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

[Bob Briscoe <[e-mail]>]

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