Re: [re-ECN] BoF draft charter
Michael Menth <menth@informatik.uni-wuerzburg.de> Tue, 29 September 2009 14:37 UTC
Return-Path: <menth@informatik.uni-wuerzburg.de>
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 0145828C163 for <re-ecn@core3.amsl.com>;
Tue, 29 Sep 2009 07:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.049
X-Spam-Level:
X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200,
BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 jrU+xPJCuwmn for
<re-ecn@core3.amsl.com>; Tue, 29 Sep 2009 07:37:19 -0700 (PDT)
Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de
[132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 84D863A6945 for
<re-ecn@ietf.org>; Tue, 29 Sep 2009 07:37:19 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail
(Postfix) with ESMTP id 085E45B8C0; Tue, 29 Sep 2009 16:38:40 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix)
with ESMTP id 053CB5B02A; Tue, 29 Sep 2009 16:38:40 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (unknown [78.52.210.31]) by
mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id B75105CC8D;
Tue, 29 Sep 2009 16:38:39 +0200 (CEST)
Message-ID: <4AC21BC9.6050504@informatik.uni-wuerzburg.de>
Date: Tue, 29 Sep 2009 16:38:01 +0200
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: toby.moncaster@bt.com
References: <AEDCAF87EEC94F49BA92EBDD49854CC70D418211@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70D418211@E03MVZ1-UKDY.domain1.systemhost.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] BoF draft charter
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
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: Tue, 29 Sep 2009 14:37:21 -0000
Hi Toby and all, I am lacking a bit the structure in this text. I tried to improve this a bit. Why congestion exposure? So far, when congestion occurs, it can be made visible to the downstream path of a flow, e.g., through ECN marks. However, a node has no means to predict the congestion traffic is causing on its downstream path. Such information can be useful to fight against traffic that is excessively causing congestion further down its path, for accounting between ISPs, or many other purposes. What is the WG planning to do? The Congestion Exposure Working Group develops mechanisms so that an end-host or a proxy can add information about the expected overall congestion on a flow's path to the network layer of the Internet. Having also information in the network layer about the congestion caused on the upstream path of a flow, the downstream congestion can be quantified. The group will consider mechanisms that require modification of the end-hosts as well as proxy mechanisms that allow network operators to do this on behalf of the end-hosts. The initial output of this group is expected to be informational or experimental. What is the expected impact of congestion exposure on other fields? Related work ... Regards, Michael toby.moncaster@bt.com schrieb: > > And a brief email about the charter: > > The easiest way to converge to a draft charter is to try and lift text > from one or more of: the BoF proposal Bob submitted; the briefer > proposal I and others came up with; the draft problem statement. We > then need to come up with a realistic list of work items taking into > account Lars’s comments regarding the level of detail required. > > Here is my initial attempt at something just to get things going. > > Congestion Exposure > > The Congestion Exposure Working Group develops mechanisms to enable > congestion to be exposed within the network layer of the Internet. The > group will consider mechanisms that require modification of the > end-hosts as well as proxy mechanisms that allow network operators to > do this on behalf of the end-hosts. The initial output of this group > is expected to be informational or experimental. > > Other work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at > new approaches to controlling bulk data transfer rates. But these new > approaches will only work with the cooperation of the operators. What > is lacking is a mechanism to build trust between operators and > end-users and between different tiers of operators. In short the > Internet lacks a system for accountability. > The last paragraph distracts my attention from what the working group is about. > The congestion exposure protocols developed by this group will enable > operators to monitor traffic according to the actual impact it is > having on other users. This will in turn allow the growth of > transports that seek to reduce their congestion impact. > > This Congestion exposure group focuses on exposing the congestion > information that end systems use to determine their transmission. > Openly propagating congestion information can provide the foundations > for trust and accountability throughout the network. Specifically, the > protocols to be considered by this group will expose both the > congestion thus far and the expected rest-of-path congestion in the IP > header of each packet. This ensures that nodes downstream of the > source can see the impact that will be caused by any packet they forward. > > Currently a protocol called re-ECN (re-inserted explicit congestion > > notification) has been proposed to do this. Re-ECN is the strongest > candidate for adoption, but of course the working group is expected to > redesign and thoroughly test this alongside any alternative if one > surfaces. > > The WG will publish a protocol which enables network operators to > count the volume of congestion for any chosen aggregate of traffic, > whether per customer, per peer, or any other aggregate. The defined > protocol should work with minimal changes to the existing network, in > particular it should work with unmodified routers, but in the long run > it is envisaged these small changes will make a big impact to how the > limited resources of the network are shared. > > The working group will NOT mandate how exposed congestion should be > used. It will confine itself to the focused task of defining the > protocol for exposing congestion. However, it will strongly encourage > experiments into how this information can be used and will ultimately > produce guidance on the dos and don'ts of using this information. > > The proposed work items for this group are: > > 1) An informational document giving the motivations for congestion > > transparency and specifying the requirements for any protocol > > 2) An experimental protocol for congestion transparency. This is > likely to be based upon the proposed re-ECN protocol as significant > research work has already been done to understand and test this > protocol and several implementations already exist. > > 3) One or more informational documents reporting the results of > > experiments on applications of the congestion transparency protocol. > > Specifically these experiments will look at ways to ensure honest > disclosure of congestion information and means to ration congestion on > a per-user basis. > > The initial goal is that all the output of the working group will be > informational or experimental, but once the experiments have been > completed then they will be used to determine if this approach should > be standardised within the IETF. > > ------------------------------------------------------------------------ > > _______________________________________________ > re-ECN mailing list > re-ECN@ietf.org > https://www.ietf.org/mailman/listinfo/re-ecn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn
- [re-ECN] BoF draft charter toby.moncaster
- Re: [re-ECN] BoF draft charter Michael Menth
- Re: [re-ECN] BoF draft charter philip.eardley
- Re: [re-ECN] BoF draft charter toby.moncaster
- Re: [re-ECN] BoF draft charter philip.eardley
- Re: [re-ECN] BoF draft charter toby.moncaster