Re: [re-ECN] preliminary draft of problem statement- authors wanted

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Tue, 29 September 2009 00:59 UTC

Return-Path: <rbriscoe@jungle.bt.co.uk>
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 47A6B3A672E for <re-ecn@core3.amsl.com>; Mon, 28 Sep 2009 17:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.584
X-Spam-Level:
X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
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 REPVuTdEFv27 for <re-ecn@core3.amsl.com>; Mon, 28 Sep 2009 17:59:02 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 982743A6831 for <re-ecn@ietf.org>; Mon, 28 Sep 2009 17:59:01 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 02:00:20 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Sep 2009 02:00:15 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1254186014386; Tue, 29 Sep 2009 02:00:14 +0100
Received: from MUT.jungle.bt.co.uk ([10.73.192.22]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n8T108Fi032126; Tue, 29 Sep 2009 02:00:08 +0100
Message-Id: <200909290100.n8T108Fi032126@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 29 Sep 2009 01:59:45 +0100
To: menth@informatik.uni-wuerzburg.de
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
In-Reply-To: <4ABBFA12.5070806@informatik.uni-wuerzburg.de>
References: <AEDCAF87EEC94F49BA92EBDD49854CC70D1D1EE6@E03MVZ1-UKDY.domain1.systemhost.net> <8A82D1BFEDDE7E4597978355239BBBCB2A238B@PACDCEXCMB06.cable.comcast.com> <AEDCAF87EEC94F49BA92EBDD49854CC70D26249F@E03MVZ1-UKDY.domain1.systemhost.net> <4AB89804.8050309@ee.ucl.ac.uk> <AEDCAF87EEC94F49BA92EBDD49854CC70D2625DA@E03MVZ1-UKDY.domain1.systemhost.net> <AEDCAF87EEC94F49BA92EBDD49854CC70D2C0A7A@E03MVZ1-UKDY.domain1.systemhost.net> <4ABA95EB.7090907@informatik.uni-wuerzburg.de> <AEDCAF87EEC94F49BA92EBDD49854CC70D3160B4@E03MVZ1-UKDY.domain1.systemhost.net> <4ABBFA12.5070806@informatik.uni-wuerzburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 29 Sep 2009 01:00:15.0735 (UTC) FILETIME=[34BEE070:01CA40A0]
Cc: re-ecn@ietf.org
Subject: Re: [re-ECN] preliminary draft of problem statement- authors wanted
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: Tue, 29 Sep 2009 00:59:09 -0000

Michael,

Going back a few days in this thread... I'm concerned about using the 
phrase "...a flow reveals..." The issue is subtle.

The idea (of re-ECN) is that *packets* reveal remaining congestion on 
their respective paths. But only when measured in aggregate. The 
aggregate doesn't have to be a flow, it can be all the traffic 
passing through an interface card. Or all the traffic matching a 
link-local VLAN tag, etc.

Of course congestion is changing all the time, and the encoding is 
unary with only one bit per packet. So each packet doesn't say 
anything accurate on its own. But they do when collected into any aggregate.

So I'd prefer to say
"The idea of congestion exposure is for packets to reveal an estimate 
of the congestion they will cause on the rest of their path across 
the Internet."

I'd quite like to say (either early in the intro, or in the abstract):
"The aim is to be able to measure the volume of downstream congestion 
for any aggregate of traffic as easily as data volume can be measured 
at any granularity (per flow, per user, per any identifier, over any 
duration)."


Bob

At 00:00 25/09/2009, Michael Menth wrote:
>Hi Toby,
>
>here is some text for the abstract.
>
>>    We need to add an abstract summarising the problem and pointing
>>
>>    towards congestion exposure as an answer...
>
>I like it short:
>
>The idea of congestion exposure means that a flow reveals an 
>estimate of the congestion it causes on its remaining downstream 
>path. It makes policing or other actions depending on downstream 
>congestion in the Internet more effective and leads thereby to a 
>more efficient and fairer Internet. This document motivates the need 
>for congestion exposure and illustrates its usefulness in different 
>use cases. Therefore, actions should be taken to implement a simple 
>form of congestion exposure in the Internet.
>
>However, an enumeration for what congestion exposure may be useful 
>can help to catch the reader's interest:
>
>The idea of congestion exposure means that a flow reveals an 
>estimate of the congestion it causes on its remaining downstream 
>path. Congestion exposure may be useful for various purposes, 
>e.g.,  meaningful policing at network ingresses, congestion-based 
>accounting between ISPs, fairer bandwidth sharing among users, 
>increased trust in the congestion-responsiveness of end-systems, and 
>possibly congestion-dependent load balancing and routing. Therefore, 
>congestion exposure leads to a more efficient and fairer Internet. 
>This document motivates the need for congestion exposure and 
>illustrates its usefulness in different use cases. Therefore, 
>actions should be taken to implement a simple form of congestion 
>exposure in the Internet.
>
>The abstract may also contain a summary of the problem (I don't find 
>it's necessary in the abstract) and be placed before the text above:
>
>The Internet relies on TCP's congestion control algorithm and saved 
>it from a major congestion collapse since its adoption. However, TCP 
>is applied on a voluntary base and the bandwidth is fairly shared 
>among flows instead of users. This is problematic so that ISPs take 
>simple or advanced policing actions on some sorts of traffic. 
>However, since congestion on the downstream path of a flow is not 
>visible, these approaches possibly hit users unnecessarily and are 
>not effective enough.
>
>
>Regards,
>
>    Michael
>
>toby.moncaster@bt.com schrieb:
>>Hi Michael,
>>
>>Thanks for the useful feedback. Clearly this document is still in its
>>very early stages. I will try and produce a new version by end of the
>>week  which will hopefully address some of your comments.
>>
>>Meanwhile I am still keen to get volunteers willing to contribute chunks
>>of text for any of the sections.
>>Toby
>>
>>
>>>-----Original Message-----
>>>From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
>>>Sent: 23 September 2009 22:41
>>>To: Moncaster,T,Toby,DER3 R
>>>Cc: re-ecn@ietf.org
>>>Subject: Re: [re-ECN] preliminary draft of problem statement- authors
>>>wanted
>>>
>>>Hi Toby,
>>>
>>>I read the whole document and still it is unclear in many parts. I
>>>marked them in the attached doc-file. I hope this helps to improve its
>>>clarity.
>>>
>>>Regards,
>>>
>>>     Michael
>>>
>>>toby.moncaster@bt.com schrieb:
>>>
>>>>Hi All,
>>>>
>>>>As promised here is a new draft of the problem statement with a bit
>>>>
>>>more meat on the bones. There is still an awful lot of work to be done
>>>on this and not too much time to do it. Our absolute deadline to get
>>>something in is October 19th - only just over 3 weeks away...
>>>
>>>>As before I would welcome any contributions of text or general
>>>>
>>>comments. When I have a bit more time I will do proper xml2rfc author
>>>entries for everyone that has contributed... For political reasons I
>>>want it to be clear that this is a document that has been worked on
>>>from people across the whole range of the IETF community.
>>>
>>>>Toby
>>>>
>>>>____________________________________________________________________
>>>>Toby Moncaster, Senior Researcher, Network Infrastructure Practise
>>>>B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>---------------------------------------------------------------------
>>
>>>-
>>>
>>>>--
>>>>
>>>>_______________________________________________
>>>>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
>>>
>
>--
>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 mailing list
>re-ECN@ietf.org
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design