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