Re: [re-ECN] Two questions about CONEX

Fred Baker <fred@cisco.com> Mon, 17 May 2010 17:26 UTC

Return-Path: <fred@cisco.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 554373A6A96 for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 10:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.707
X-Spam-Level:
X-Spam-Status: No, score=-108.707 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 qcZHlAwIa8E0 for <re-ecn@core3.amsl.com>; Mon, 17 May 2010 10:26:24 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 071573A6AB4 for <re-ecn@ietf.org>; Mon, 17 May 2010 10:24:48 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFMY8UurRN+J/2dsb2JhbACdeXGjG5lShRAEg0A
X-IronPort-AV: E=Sophos;i="4.53,248,1272844800"; d="scan'208";a="326688587"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 17 May 2010 17:24:40 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4HHOXdb010440; Mon, 17 May 2010 17:24:35 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 17 May 2010 10:24:40 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 17 May 2010 10:24:40 -0700
Mime-Version: 1.0 (Apple Message framework v1078)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4BE85D4C.3030001@juniper.net>
Date: Mon, 17 May 2010 10:24:28 -0700
Message-Id: <084AC2D4-1BB4-4AAA-82DF-B87967508400@cisco.com>
References: <4BE5039A.5040003@cisco.com> <EE00404438E9444D90AEA84210DC406707FB24@pacdcexcmb05.cable.comcast.com> <4BE5A010.3000402@cisco.com> <EE00404438E9444D90AEA84210DC406707FB28@pacdcexcmb05.cable.comcast.com> <4BE85D4C.3030001@juniper.net>
To: Ron Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1078)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] Two questions about CONEX
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 17:26:25 -0000

On May 10, 2010, at 12:23 PM, Ron Bonica wrote:

> I think that we should charter a WG and task that WG with the
> development of exactly one document. That document captures use cases in
> which the ip-layer does something useful with congestion information.
> (This is currently out of scope for CONEX).

I think this is too narrow a scope. I think the document should describe use cases for conex. 

Consider RFC 3168 as a prototype for this document. It identifies that the network can easily and cheaply flag congestion events (far more cheaply than with IPFIX, and far more accurately), but it also identifies that the responsibility for responding to the event lies in the transport layer. If you had put this requirement on the authors of RFC 3168, they would not have been able to describe what is in fact a very useful capability. (IMHO, either RFC 3168 or a delay-based congestion avoidance procedure in the transport would be very sufficient for ledbat, for example).

I don't think you actually need a WG for this document. What you need is for individuals that have use cases to post drafts describing them. If conex wants to pull those together into a use case document, they can do that at their leisure.