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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
