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

John Leslie <john@jlc.net> Wed, 21 October 2009 16:37 UTC

Return-Path: <john@jlc.net>
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 7F20C28C101 for <re-ecn@core3.amsl.com>; Wed, 21 Oct 2009 09:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 dt9jkFlODLFP for <re-ecn@core3.amsl.com>; Wed, 21 Oct 2009 09:37:27 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 988CE28C0FE for <re-ecn@ietf.org>; Wed, 21 Oct 2009 09:37:24 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 0814633C6E; Wed, 21 Oct 2009 12:37:33 -0400 (EDT)
Date: Wed, 21 Oct 2009 12:37:32 -0400
From: John Leslie <john@jlc.net>
To: toby.moncaster@bt.com
Message-ID: <20091021163732.GE78898@verdi>
References: <AEDCAF87EEC94F49BA92EBDD49854CC70D917C61@E03MVZ1-UKDY.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC063639C4@E03MVB1-UKBR.domain1.systemhost.net> <AEDCAF87EEC94F49BA92EBDD49854CC70D917DD2@E03MVZ1-UKDY.domain1.systemhost.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70D917DD2@E03MVZ1-UKDY.domain1.systemhost.net>
User-Agent: Mutt/1.4.1i
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: Wed, 21 Oct 2009 16:37:28 -0000

toby.moncaster@bt.com <toby.moncaster@bt.com> wrote:
> 
> I think I would rather say something slightly different about TCP.
> How about making the whole:
> 
> " The Internet is, in essence, about pooling resources. The ability to
> share capacity has been paramount to its success and has traditionally
> relied on the voluntary use of TCP congestion control. However, TCP
> may not be the most suitable algorithm for applications such as
> peer-to-peer or streaming video that break some of its fundamental
> design assumptions.

   Yes!

> Such applications are able to cause enough congestion over time to
> severely impair the quality of experience of other users.

   True, but not quite right. Perhaps:
" 
" Such applications need to be a bit more aggressive than TCP under
" some circumstances even if they are less aggressive on average. ISPs
" are unable to tell whether such applications are, on average, more
" or less aggressive than standard TCP congestion-control.

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

   Yes.

> The consequences of such practices are increasing calls for government
> regulation and stifling innovation at the transport and application
> layer (see for example, the problem statement I-D (ref below) and
> RFC5594)."

   The reader stumbles a bit over this. Perhaps:
" 
" Since such practices cannot distinguish whether the policing actually
" matches the problem, they tend to stifle innovation at the transport
" and application layers. Also, such practices often appear to be aimed
" at stifling competitors to those ISPs, leading to increasing calls for
" government regulation.

--
John Leslie <john@jlc.net>