Re: [re-ECN] Charter Question

"McCann Peter-A001034" <pete.mccann@motorola.com> Mon, 17 May 2010 15:37 UTC

Return-Path: <pete.mccann@motorola.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 1AE2328C11B for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 08:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.246
X-Spam-Level:
X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_50=0.001, 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 boURjWhsWwVV for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 08:37:30 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id F07273A688E for <re-ecn@ietf.org>; Mon, 17 May 2010 08:34:23 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-10.tower-119.messagelabs.com!1274110450!42607176!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 5605 invoked from network); 17 May 2010 15:34:10 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 May 2010 15:34:10 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o4HFYAL9000526 for <re-ecn@ietf.org>; Mon, 17 May 2010 08:34:10 -0700 (MST)
Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o4HFYA3L020827 for <re-ecn@ietf.org>; Mon, 17 May 2010 10:34:10 -0500 (CDT)
Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o4HFY9su020821 for <re-ecn@ietf.org>; Mon, 17 May 2010 10:34:09 -0500 (CDT)
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: Mon, 17 May 2010 11:33:48 -0400
Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC06B2F753@de01exm70.ds.mot.com>
In-Reply-To: <20100517143717.GF2670@verdi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [re-ECN] Charter Question
Thread-Index: Acr1zr++hJ96iGM+SqmYjHpexIxmSAABzsrg
References: <201005171056.o4HAu2pt029111@bagheera.jungle.bt.co.uk><01b401caf5bd$07acce30$0600a8c0@china.huawei.com> <20100517143717.GF2670@verdi>
From: McCann Peter-A001034 <pete.mccann@motorola.com>
To: John Leslie <john@jlc.net>, David Harrington <ietfdbh@comcast.net>
X-CFilter-Loop: Reflected
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] Charter Question
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: Mon, 17 May 2010 15:37:31 -0000

John Leslie wrote:
> David Harrington <ietfdbh@comcast.net> wrote:
>> As a vendor, if I supported a re-ecn,
> 
>    Wait a second... what might it mean for a "vendor" to "support"
> ConEx?
> 
>    The first example is an Operating-System vendor. An OS "supports"
> ConEx by putting ConEx markings in IP packets it originates --
> otherwise the markings can't get there. It is likely that an OS
> vendor would automate what ConEx markings based upon congestion
> feedback, within its TCP/IP stack.   
> 
>    The next example is a middlebox vendor. A middlebox might perform
> accounting and/or policing for congestion-expected packet volume. 
> 
>    IMHO, a backbone-router vendor is _not_ an example. Backbone
> routers either do or don't support ECN marking in place of dropping
> packets. (A end-customer-router might well perform middlebox tasks,
> but I prefer to group it with other middleboxes.)   

It would still be desirable to implement the preferential dropping
scheme on congested links in the backbone, no?  Or are you assuming
that with universal deployment of ECN, we would never get the congestion
in the backbone that would necessitate dropping?

-Pete