Re: [re-ECN] FW: ConEx BoF announcement text

João Taveira Araújo <j.araujo@ee.ucl.ac.uk> Sun, 25 October 2009 23:53 UTC

Return-Path: <j.araujo@ee.ucl.ac.uk>
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 B92FB3A6A19 for <re-ecn@core3.amsl.com>; Sun, 25 Oct 2009 16:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 dsJ3apTSptOZ for <re-ecn@core3.amsl.com>; Sun, 25 Oct 2009 16:53:53 -0700 (PDT)
Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id 5D8533A6A18 for <re-ecn@ietf.org>; Sun, 25 Oct 2009 16:53:53 -0700 (PDT)
Received: from [192.168.1.64] (host86-177-114-148.range86-177.btcentralplus.com [86.177.114.148]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id n9PNroPP018104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Oct 2009 23:53:55 GMT
Message-ID: <4AE4E509.1090008@ee.ucl.ac.uk>
Date: Sun, 25 Oct 2009 23:53:45 +0000
From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= <j.araujo@ee.ucl.ac.uk>
Organization: UCL
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Leslie Daigle <leslie@thinkingcat.com>
References: <4A916DBC72536E419A0BD955EDECEDEC0636399B@E03MVB1-UKBR.domain1.systemhost.net> <4ADD187E.6000200@thinkingcat.com> <200910221807.n9MI7P2a002071@bagheera.jungle.bt.co.uk> <4AE26D76.7090701@thinkingcat.com>
In-Reply-To: <4AE26D76.7090701@thinkingcat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information
X-MailScanner-ID: n9PNroPP018104
X-UCL_EE-MailScanner: Found to be clean
X-UCL_EE-MailScanner-From: j.araujo@ee.ucl.ac.uk
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] FW: ConEx BoF announcement text
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: Sun, 25 Oct 2009 23:53:53 -0000

Hi,

Here goes an attempt at making this paragraph a little less confusing by 
splitting it in two and a bit of rephrasing. The last sentence is still 
a little confusing though.

Leslie Daigle wrote:
> <on the wiki, to be replaced:>
> 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 congestion control. 
> However, TCP alone is unable to prevent bandwidth intensive 
> applications, such as peer-to-peer or streaming video, from causing 
> enough congestion over time to severely limit the user-experience of 
> many other users. This has led ISPs to deploy ad-hoc solutions such as 
> volume accounting, rate policing and deep packet inspection in an 
> attempt to distribute capacity differently. The consequences of such 
> practices are increasingly leading to calls for government regulations 
> and stifling innovation at the transport and application layer (see 
> for example, the problem statement I-D (ref below) and RFC5594).
> </on the wiki>

<my attempt>
However, TCP alone provides neither the means nor the incentives for 
applications to limit the congestion they inflict on others, resulting in a
troubled coexistence between applications with differing needs.  High 
traffic applications, such as peer-to-peer or streaming video, are 
unable or unwilling to restrain themselves from causing enough 
congestion over time to severely limit the user-experience of many other 
users.

This has led ISPs to deploy ad-hoc solutions such as volume accounting, 
rate policing and deep packet inspection in an attempt to distribute 
capacity differently.  Such practices ostracize an entire class of 
applications for simply attempting to pool available capacity, 
consequently stifling innovation at the transport and application layer, 
as well as increasingly leading to calls for government regulations (see 
for example, the problem statement I-D (ref below) and RFC5594).
</my attempt>

Cheers,
Joao