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

[<[e-mail]>]

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. 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.
> 
>    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

> > 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.
> 
> > 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

> 
> > 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

> 
> > 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

> 
>    And add, "The protocol should work with the substantial majority of
> existing routers needing no modification whatsoever."

Yes

> 
> > 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...

> 
> > 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'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"?

> 
> >    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)

> 
> --
> John Leslie <[e-mail]>