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

[John Leslie <[e-mail]>]

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

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

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

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

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

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

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

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

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

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

>    and the impact of rationing the congestion volume a given user or
>    network can cause.

   I don't quite get the point here.

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

--
John Leslie <[e-mail]>