Piers,
OK. Text altered (even tho some of the gains are much less sensitive
to marking scheme, the point is of course generally true).
Bob
At 13:26 07/11/2013, Piers O'Hanlon wrote:
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
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
