Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

Bob,

I was thinking that it would be good to add the following clarifications:

Given a suitable marking scheme ECN provides for the removal of nearly all congestion loss and it reduces delays for two main reasons: 
  i) It avoids the delay when recovering from congestion losses, which particularly benefits small flows, making their 
      completion time predictably short [RFC2884]
  ii) As ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay
      into buffers before they start to notify congestion (the cause of bufferbloat). 
The latter delay is because a drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal not an impairment, so there is no harm triggering it earlier.

Cheers,

Piers

On 5 Nov 2013, at 18:41, Bob Briscoe wrote:

> Piers,
> 
> I tried to state exactly how ECN can benefit (2nd para of intro below), rather than make overblown claims. You seem to be saying I didn't succeed? I can't see how to do any better. Suggestions?
> 
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> ECN removes nearly all congestion loss and it cuts delays for two main reasons: i) it avoids the delay when recovering from congestion losses, which particularly benefits small flows, making their completion time predictably short [RFC2884] and ii) as ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). The latter delay is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal not an impairment, so there is no harm triggering it earlier.
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> 
> PS. Thx for supporting words.
> 
> Bob
> 
> At 09:42 05/11/2013, Piers O'Hanlon wrote:
>> Hi Bob,
>> 
>> I took a brief look at the draft and it's clearly useful work.
>> 
>> One thing that could do with clarification in the Introduction is that ECN - by itself - doesn't necessarily lead to low loss and delay - it should be made clear that it reflects the marking approach of the underlying scheme/AQM.
>> 
>> Piers
>> 
>> On 4 Nov 2013, at 22:03, Bob Briscoe wrote:
>> 
>> > Folks,
>> >
>> > Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.
>> > Even better, if you're willing to read / comment / review / implement
>> >
>> > Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
>> > <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
>> >
>> > Abstract
>> >
>> >   The purpose of this document is to guide the design of congestion
>> >   notification in any lower layer or tunnelling protocol that
>> >   encapsulates IP.  The aim is for explicit congestion signals to
>> >   propagate consistently from lower layer protocols into IP.  Then the
>> >   IP internetwork layer can act as a portability layer to carry
>> >   congestion notification from non-IP-aware congested nodes up to the
>> >   transport layer (L4).  Following these guidelines should assure
>> >   interworking between new lower layer congestion notification
>> >   mechanisms, whether specified by the IETF or other standards bodies.
>> >
>> >
>> > [Cross-posting tsvwg & aqm, just in case]
>> >
>> >
>> > Bob Briscoe,
>> > also for co-authors Pat Thaler and John Kaippallimalil
>> >
>> >
>> > ________________________________________________________________
>> > Bob Briscoe,                                                  BT
>> 
>> _______________________________________________
>> aqm mailing list
>> aqm@ietf.org
>> https://www.ietf.org/mailman/listinfo/aqm
> 
> ________________________________________________________________
> Bob Briscoe,                                                  BT 