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

[Bob Briscoe <[e-mail]>]

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT