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

[Michael Menth <[e-mail]>]

Hi Bob,

I believe we should substitute "flows" by "traffic" and not by "packets" 
becaus traffic is a more general aggregation of packets than flows:

The idea of congestion exposure means that traffic 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.

Regards,

    Michael

Bob Briscoe schrieb:
> 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
>>
>> [e-mail] 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:[e-mail]]
>>>> Sent: 23 September 2009 22:41
>>>> To: Moncaster,T,Toby,DER3 R
>>>> Cc: [e-mail]
>>>> 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
>>>>
>>>> [e-mail] 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.  [phone]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> -
>>>>
>>>>> -- 
>>>>>
>>>>> _______________________________________________
>>>>> re-ECN mailing list
>>>>> [e-mail]
>>>>> 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: [phone] (new), fax: [phone]
>>>> mailto:[e-mail]
>>>> 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: [phone] (new), fax: [phone]
>> mailto:[e-mail]
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>> _______________________________________________
>> re-ECN mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/re-ecn
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone] (new), fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn