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

[<[e-mail]>]

Hi Steve, João,

Thanks for the very prompt and extensive comments. I have accepted pretty much all of Steve's new text and have tried to add in those suggestion from João that are still relevant to the new text. Here is the revised version. One thing I wasn't sure about was whether to mention PCN (or more specifically Bob's re-PCN) as being a similar approach that works for inelastic realtime traffic... On balance I think not.

-----------------

One of the strengths of the Internet is its ability to share capacity and avoid congestion collapse by 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 other 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. 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.

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 queuing, volume-based billing) to the crude (per-application prioritization or rate capping).  A problem with such mechanisms is that they control the wrong quantity: it is not the total volume or absolute rate of traffic of a particular user or application that impedes service to other users; rather, it is the excess traffic that causes others to experience congestion that is the real problem.

Current work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at new approaches for controlling bulk data transfer rates.  But ISPs have no means for enforcing their use and indeed may even be hindering their deployment through their crude attempts at traffic control. This means the ISPs still have an incentive to deploy the flawed tools at their disposal to manage capacity and reduce congestion.  What ISPs lack is a way to measure or even see the congestion caused by a user’s excess traffic 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.

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 upstream and expected downstream 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. This will serve to correct the current issues of information asymmetry [http://www.soton.ac.uk/~ram2/papers/ccm3.pdf]. 

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.


---------------------

I am quite sure it still needs more bashing and I am not at all precious about what I write - my view is that we need to get something in reasonable shape in the next 3 weeks. By the beginning of next week I am intending to put out a preliminary I-D and would love to have some volunteers as co-authors. Before that stage I also need to settle on a rough ToC for the remainder of the document. I imagine it would roughly follow the 3 main sections in the current document - issues with excessive congestion, ISPs attempts to control this, our proposal to do this better. In the latter section I will probably use a strawman protocol where the precise congestion level (e.g. p in the famous Padhye TCP throughput equations) is somehow encoded into the IP header.

Toby



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 08 September 2009 19:38
> To: Moncaster,T,Toby,DER3 R
> Cc: [e-mail]; [e-mail]
> Subject: Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF
> inHiroshima?
> 
> 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