Re: [re-ECN] Charter Question

bmanning@vacation.karoshi.com Fri, 07 May 2010 18:21 UTC

Return-Path: <bmanning@karoshi.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 2F3F53A6907 for <re-ecn@core3.amsl.com>; Fri, 7 May 2010 11:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.507
X-Spam-Level:
X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=-0.508, 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 o7QmwIi4iV4E for <re-ecn@core3.amsl.com>; Fri, 7 May 2010 11:21:20 -0700 (PDT)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 8600D3A686D for <re-ecn@ietf.org>; Fri, 7 May 2010 11:18:04 -0700 (PDT)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id o47IGktG004456; Fri, 7 May 2010 18:17:01 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id o47IGLZn004453; Fri, 7 May 2010 18:16:21 GMT
Date: Fri, 07 May 2010 18:16:16 +0000
From: bmanning@vacation.karoshi.com
To: John Leslie <john@jlc.net>
Message-ID: <20100507181616.GA4331@vacation.karoshi.com.>
References: <4BE42A91.2040202@juniper.net> <20100507165938.GB48545@verdi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100507165938.GB48545@verdi>
User-Agent: Mutt/1.4.1i
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: Fri, 07 May 2010 18:21:23 -0000

On Fri, May 07, 2010 at 12:59:38PM -0400, John Leslie wrote:


>    Our principal intent is to have a forwarding-layer mechanism to
> distinguish flows that intend to operate despite congestion from those
> that intend to avoid congestion. Clearly routers forwarding onto
> uncongested links do not need to distinguish these, while routers
> that know they're forwarding onto a congested path might have reason
> to treat them differently (though we don't yet know how), and
> customer-facing routers might wish to enforce limits on the amount
> of congestion-expected traffic.
> 
>    Generally, I don't believe we're at the point where it makes sense
> to describe how routers would use the information -- so I have no
> intent to speak for the list-members on this: but I do believe Ron
> is entitled to some indication where we're coming from.
> 
>    We're talking about a mechanism to have a uniform view of path
> congestion along a forwarding path, not about any particular method
> of dealing with the congestion. We believe such information can
> inform better congestion-control mechanisms extending past the
> foreseeable future.

	ok, then I am confused by your POV.  are we talking about a
	binary switch (congested/notcongested) or are we talking about
	preference/priority - with a range of values?  if the former,
	then its not really applicable to the flow, end/end, since the
	"inspecting forwarder" may in fact be the cause of the congestion.
	if its a range, then how is this different than QOS?

--bill

> 
> --
> John Leslie <john@jlc.net>
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn