Re: [re-ECN] Charter Question

John Leslie <> Mon, 10 May 2010 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 730A828C20A for <>; Mon, 10 May 2010 10:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.507
X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mMeKf36qLwq5 for <>; Mon, 10 May 2010 10:47:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9D0B93A6964 for <>; Mon, 10 May 2010 10:44:04 -0700 (PDT)
Received: by (Postfix, from userid 104) id EE1AC33D19; Mon, 10 May 2010 13:43:53 -0400 (EDT)
Date: Mon, 10 May 2010 13:43:53 -0400
From: John Leslie <>
To: Ron Bonica <>
Message-ID: <20100510174353.GI48545@verdi>
References: <> <20100507165938.GB48545@verdi> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Subject: Re: [re-ECN] Charter Question
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 May 2010 17:47:27 -0000

Ron Bonica <> wrote:
>>> If I do have this right, who will those routers use this information?
>> I believe we consider that question out of scope; 
> This is troubling. Before we invest in tool development, we really
> should know something about the intended use of the tool.

   We certainly have a lot of information on that developed by Bob
Briscoe, e.g.

   I realize that not everyone agrees with Bob; so let me try to give
an independent viewpoint on use of a ConEx tool.

   Recall, the proposed charter says:
] The mechanism to be developed by the CONEX WG will enable the sender
] to also relay the congestion information back into the IP layer,
] such that the total level of congestion is visible to all IP devices
] along the path.

   Thus, at any point along the path -- most likely near the sender
or near the receiver -- it will be practical to aggregate the expected
congestion for some flows and see whether this is consistent with the
contractual arrangement.

   What to do if it isn't is clearly out-of-scope.

   How to ensure better service for flows that correctly mark the
expected congestion is mostly out-of-scope. Diffserv and source-
routing through special paths known to be less congested come to
mind; but any method whatsoever is fine, and even no method at all
may prove quite workable -- that is a business decision for the ISP

   This -- and only this -- is "the intended use of the tool".

   Being who we are, we inevitably speculate about other uses such
a tool will enable. Any good tool enables uses beyond the one it
was designed for.

> I wouldn't mind letting the BoF spend some time bringing this question
> into focus before chartering a WG.

   What "better focus" would you like, Ron?

John Leslie <>