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

[<[e-mail]>]

On Tue, 8 Sep 2009 16:55:33 +0100, <[e-mail]> wrote:

> OK, as promised here is the opening page of a problem statement about
> congestion exposure. Before going any further with this I would be glad
> to get feedback from people on the list, especially those that have
> experience in this area. I am not really happy with the last paragraph
> and am not sure if we even want to go there. I am contemplating instead
> referencing a new version of draft-briscoe-tsvwg-relax-fairness-01.txt
> (expired, but it should be available somewhere, bobbriscoe.net if
> nowhere else):
> 
> 
> A problem statement motivating the need for congestion exposure

Toby,

I think the basic message here is fine, but phrasing it in a set of
questions rather than declarative statements does not work, IMHO.  Please
consider the included text as an alternative.

> The Internet has been a phenomenal success. But for how much longer can
> that success last? As access networks get faster and faster, the nature
> of the network is changing. New applications appear every year, each in
> turn making greater and greater demands on the infrastructure. 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 eroding trust between ISPs, customers,
> content providers and application writers.

Replace with:

Currently, the Internet shares capacity and avoids congestion collapse
using distributed algorithms executed on its end-hosts.  While the
resulting allocation of capacity is fair in a certain mathematical sense,
it is not necessarily fair in certain economic or philosophical senses. 
Further, end-hosts have means to "game the system" to increase their access
to capacity, and to progress communications even in the presence of
persistent congestion.

> Their motives for behaving like this are perfectly understandable - they
> want the majority of their customers to receive a good service. The
> problem is that in trying to control these so-called heavy users, ISPs
> are seeking to control the wrong thing. It isn't the volume of data a
> user sends that causes problems; it is trying to send too much data when
> everyone else is that is the problem - it is a gross simplification to
> assume that a user sending lots of data must be causing lots of
> congestion. By "punishing" traffic regardless of the impact it is
> having, these ISPs are second-guessing their customers priorities and
> not allowing them the freedom to prioritise their own traffic.

Replace with:

ISPs have a variety of measures available to them to reduce congestion, or
to skew access to capacity amongst their users, ranging from the complex
(per-user fair queueing, volume-based billing) to the crude
(per-application prioritization).  A problem with such mechanisms is that
they control the wrong quantity: it is not the total traffic of a
particular user or application that impedes service to other users, but it
is the congestion-causing excess traffic.

> Current 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 if the operators stop limiting traffic purely
> based on application type. 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.

Replace with:

Current work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at new
approaches to controlling bulk data transfer rates.  But ISPs have no means
for enforcing their use, and hence still have incentives to deploy the
tools at their disposal to manage capacity and reduce congestion.  What
ISPs lack is a way to measure the congestion-causing excess traffic of a
user on an end-to-end basis.  Such a measure could be used to build trust
between operators and end-users and between different tiers of operators.
In short the Internet lacks a system for accountability.

> So what is the solution? Well the first stage is to be more open about
> the information end-hosts are using to determine their sending rate -
> congestion along the path. Currently this information is visible to the
> end-points but is concealed from the rest of the network. It is our
> thesis that this information should be made visible at the IP layer -
> the waist of the hourglass. Specifically, the protocols to be considered
> by this BoF will expose the actual congestion and 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. 

Replace with:

Currently, congestion information is visible only at end-hosts, and is
concealed from the rest of the network.  We propose that this information
should be made visible at the IP layer - the waist of the hourglass.
Specifically, the protocols to be considered by this BoF will expose the
actual congestion and 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. 

> Once the information is there, it is then possible to use it to measure
> the true impact of this traffic on the network. Rather than counting
> volume, a node in the network now counts congestion volume - the
> remaining congestion along the path multiplied by the size of the
> packet. This reflects the excess data that packet is trying to push
> through the network and make this a measure of the marginal cost of
> forwarding that packet.

Replace with:

Once congestion information is exposed in this way, it is then possible to
use it to measure the true impact of this traffic on the network. Rather
than counting total traffic volume, a node in the network may now count
congestion volume.



Regards,

// Steve