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

<toby.moncaster@bt.com> Tue, 08 September 2009 15:55 UTC

Return-Path: <toby.moncaster@bt.com>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F9F3A6AAA for <re-ecn@core3.amsl.com>; Tue, 8 Sep 2009 08:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPfVVybnqdql for <re-ecn@core3.amsl.com>; Tue, 8 Sep 2009 08:55:07 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BCEB23A69C5 for <re-ecn@ietf.org>; Tue, 8 Sep 2009 08:55:06 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 16:55:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 08 Sep 2009 16:55:33 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70CF81803@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CF2BCE5@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF inHiroshima?
Thread-Index: AcowbOBDm+bk6tUHQLKnuACLToj3YAAALuLQAAuuhYA=
References: <200909071019.n87AJgBB030579@bagheera.jungle.bt.co.uk><AEDCAF87EEC94F49BA92EBDD49854CC70CEB8418@E03MVZ1-UKDY.domain1.systemhost.net><8A82D1BFEDDE7E4597978355239BBBCB04389F@PACDCEXCMB06.cable.comcast.com><AEDCAF87EEC94F49BA92EBDD49854CC70CF2B7C9@E03MVZ1-UKDY.domain1.systemhost.net><20090907164107.GR8532@verdi><AEDCAF87EEC94F49BA92EBDD49854CC70CF2B885@E03MVZ1-UKDY.domain1.systemhost.net><200909080035.n880Zs1t012039@bagheera.jungle.bt.co.uk><AEDCAF87EEC94F49BA92EBDD49854CC70CF2BAD1@E03MVZ1-UKDY.domain1.systemhost.net><7D6FD9F3-B80E-4227-B215-EA22F20552CF@g11.org.uk> <AEDCAF87EEC94F49BA92EBDD49854CC70CF2BCE5@E03MVZ1-UKDY.domain1.systemhost.net>
From: toby.moncaster@bt.com
To: toby.moncaster@bt.com, carlberg@g11.org.uk
X-OriginalArrivalTime: 08 Sep 2009 15:55:36.0397 (UTC) FILETIME=[CE149FD0:01CA309C]
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF inHiroshima?
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2009 15:55:08 -0000

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

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.

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.

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.

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. 

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.



> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
> Behalf Of toby.moncaster@bt.com
> Sent: 08 September 2009 11:19
> To: carlberg@g11.org.uk
> Cc: re-ecn@ietf.org
> Subject: Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF
> inHiroshima?
> 
> That's a much clearer way of phrasing what I was trying to say :-)
> 
> I am working on a draft problem statement and should have an
> introduction available for people to comment on in a few hours...
> 
> Toby
> 
> > -----Original Message-----
> > From: ken carlberg [mailto:carlberg@g11.org.uk]
> > Sent: 08 September 2009 11:12
> > To: Moncaster,T,Toby,DER3 R
> > Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; re-ecn@ietf.org
> > Subject: Re: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> > Hiroshima?
> >
> >
> > On Sep 8, 2009, at 4:52 AM, <toby.moncaster@bt.com> wrote:
> >
> > > 2) Define EXACTLY the problem we are addressing (by writing a
> problem
> > > statement document). And keep this concise and focussed (e.g. only
> > > concentrate on a single aspect).
> >
> > one other thing that is related and helpful in this initial process
> is
> > to bring up a discussion of what is and is not in scope for the BoF.
> >
> > -ken
> 
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn