Re: [re-ECN] ConEx BoF announcement

[John Leslie <[e-mail]>]

Jo?o Taveira Ara?jo <[e-mail]> wrote:

> Congestion Exposure (ConEx) is a proposed new IETF activity to enable
> congestion to be exposed within the network layer of the Internet.

   I think the point is "exposed along the forwarding path" in the
network (IP) layer.

   Further, AFAIK what will be exposed is both "expected congestion" and
"congestion experienced so far". (This sounds like magic, of course, and
we should perhaps take some pains to convince readers it is merely
"sufficiently advanced technology" ;^)

> By revealing expected congestion in the IP header of every packet,

   Here's a good place to start dispelling the "magic" appearance.
AFAIK we don't intend to put a high-precision number in every packet,
but instead to put one bit in some fraction of packets sent, in
proportion to the congestion expected. The former sounds like magic;
the latter like advanced technology.

> congestion exposure provides a generic network capability which
> simplifies resource allocation.

   I'm not sure "simplifies" is correct -- instead I think we mean
"enables better resource allocation".

> This information may in turn be used for multiple purposes, including
> congestion policing, inter-domain SLAs, end-to-end QoS and traffic
> engineering.

   It's sounding like magic again... I don't think those should be run
together.

   For congestion policing, we might say something like
" 
" At any point along the forwarding path, such as a peering point, a
" congestion policing function could check whether the percentage of
" congestion-expected-marked packets exceeds the contracted percentage,
" and assess additional charges or refuse some of the traffic.

   The other items are too broad for me to wordsmith at this time...

> The internet is, in essence, about pooling resources. The ability to
> share capacity has been paramount to its success and has traditionally
> been managed through the voluntary use of TCP.

   "TCP congestion-control", I think.

> TCP alone however is unable to prevent bandwidth intensive applications,
> such as peer-to-peer or streaming video, from causing enough congestion
> to severely limit the user-experience of many other end-hosts.

   This isn't the right emphasis, IMHO. Let me try to shift the emphasis:
" 
" Traditional TCP congestion-control, however, is proving ill-suited to
" the needs of bandwidth-intensive applications such as streaming audio
" and video. Similarly, background-file-sharing applications are finding
" a need for alternative congestion-control when congestion limits the
" ability of TCP to ever fill the available bandwidth.

> This has lead ISPs to deploy ad-hoc solutions such as volume accounting,
> rate policing and deep packet inspection in an attempt to distribute
> capacity differently.

   Although I hate the concept of distributing "fairly", that is what
they claim to be attempting, and I think we should use their word.

> It is increasingly recognised that in today's internet this leads to
> issues from technical, business and regulatory viewpoints [ref problem
> statement, p2pi workshop].

   This sentence is a bit hard to read. Perhaps:
" 
" The consequences of such ISP practices are increasingly leading to
" calls for government regulations.

> The heart of the problem is that the internet lacks a system for
> accountability for causing congestion - accountability for end users
> to networks, networks to networks, and networks to end users.

   A bit sudden... Perhaps:
" 
" We believe these problems stem from a lack of a network-layer system
" for accountability -- among all parties -- for sending traffic which
" causes congestion.

> The key new metric proposed is that packets carry information about
> the rest-of-path congestion, so any node can see the congestion it
> causes others by sending or forwarding traffic.

   The reader stumbles a bit. Perhaps:
" 
" We propose a metric where IP packets carry information about the
" expected "rest-of-path" congestion, so that any forwarding point
" may know how much congestion it is likely to cause by forwarding
" that traffic.

> A network operator can then count the volume of congestion about to be
> caused by an aggregate of traffic as easily as it can count the volume
> of bytes entering its network today. Once ISPs can see congestion,
> they can discourage users from causing large volumes of congestion,
> and they can discourage other networks from allowing their users to
> cause congestion.  

   Good. (Magic is acceptable here. ;^)

> The main proposed item of work is to define the basic protocol that
> exposes the expected rest-of-path congestion in the IP header.
> The defined protocol should work with minimal changes to the existing
> network, in particular it should work with unmodified routers, and be
> transport-agnostic.

   Good. I'd break the paragraph here. (Transport-agnostic is our main
point -- we don't want it to get lost in the middle of a paragraph.)

> While the proposed WG will encourage experimentation with the new
> metric, it will not define in detail how exposed congestion should be
> used.

   A bit wimpy... Perhaps:
" 
" The proposed WG will not attempt to detail what management practices
" are appropriate for managing congestion, though we expect wide-ranging
" experimentation along those lines: our concern will be how well the
" protocol expresses expected and actual congestion.

> The proposed work items are:

   These need work, but not necessarily right now. In any case, I won't
address them in this email.

--
John Leslie <[e-mail]>