Re: [aqm] I-D Action: draft-ietf-aqm-ecn-benefits-04.txt

[[e-mail]]

I wonder if some of the comments could be addressed by some small additional
text, see below for some suggested text. If the new text helps, Michael
and I are happy roll another revision if you think this or similar text
can resolve some issues. Let me know what people think.

I see you also raise some scoping questions (near the end).

Comments in-line.

Gorry

> Hi Gorry, hi Michael,
>
> to catch up with this: I think most of my comments were addressed.
> Especially the
> restructuring and removing of all normative language is good. Thanks!
>
> The one point I'm still not super happy with is section 3.6 and 3.6.1. I
> don't
> think it reflects the problems and opportunities of using a different AQM
> and
> different congestion control for ECN accordingly. If I see this correctly,
> you
> didn't
> change the text very much and I think that the current text is just not
> fully
> correct.
>
> The main issue is that the text sounds like if you have accECN, you can
> just go
> ahead
> and implement a different congestion control. However, if you use
> something like
> DCTCP on the Internet, you'd be very aggressive and push away other
> traffic.
> Therefore we should be more careful what we say here. I'm not even sure if
> this
> should be discussed in the 'Benefits' section, but I do think it's
> important to
> mention in this doc. Maybe we can also ask Bob Briscoe what he think
> should be in
> this section because he has been very actively working on this recently.
>
 GF: I think points are relevant to the TCPM requirements for
 Accurate ECN. To me, they seem to be mainly of concern to transport protocol
 designers, rather than end-to-end users of the service - I’m sure work in
 TCPM will consider this, but indeed we could state something here.

Fo you think this text could cover the point as regard usage of ECN by
upper layer protocols?:

 OLD:
 This could be used by the control mechanisms in the transport to make a
 more appropriate decision on how to react to congestion, allowing it to
 react faster to changes in congestion state.

 NEW:
 This could be used by the control mechanisms in the transport to make a
 more appropriate decision on how to react to congestion, allowing it to
 react faster to changes in congestion state. Any update to the transport
 protocol requires careful consideration of the robustness of the behaviour
 when working with endpoints or network devices that were not designed for
 the new congestion reaction.

> The other smaller point is that I'd like to see more explicitly mentioned
> somewhere that ECN does not always help with tail loss because often the
> queue
> simply is too short if a large burst is sent. (Therefore avoiding burst
> might
> still be useful).
>

GF: We suggest adding text on this topic to penultimate para of section
 2.3. This text says again that loss can not be avoided, which is a point
 made in other ECN-related documents, but for clarity this could be
restated here:

 OLD:
 When incipient congestion occurs at the tail of a burst, an ECN-capable
 network device can CE-mark the packet(s), rather than triggering drop.
 This allows the transport to avoid the retransmission timeout, ...

 NEW:
 An ECN-capable network device cannot eliminate the possibility of packet
 drop. Drop may occur due to a traffic burst exceeding the instantaneous
 available capacity of a network buffer, or a a result of an AQM algorithm
 (overload protection mechanisms, etc). However, ECN-capable network
 devices that observes incipient congestion may be expected to buffer an
 ECN-capable flow and set a CE-mark in one or more packet(s), rather than
 triggering packet drop.

 Setting a CE-mark allows the transport to avoid the retransmission
 timeout, ...


>
> These are the two points I'd like to see better addressed from my review
> comments. However, based on the other comments on the list, I think there
> are more people who agree with me that this document sounds extremely
positive
> and it should more explicitly also address potentially negative
consequences.
>
GF: I'm not sure what you ask here, since the abstract states:
"The goal of this document is to describe the potential benefits when
applications use a transport that enables Explicit Congestion Notification
(ECN). The document outlines the principal gains in terms of increased
throughput, reduced delay and other benefits when ECN is used over network
paths that include equipment that supports ECN-marking. It also describes
methods that can help successful deployment of ECN. It does not propose
new algorithms to use ECN, nor does it describe the details of
implementation of ECN in endpoint devices (Internet hosts), routers or
other network devices."

> Those things are mentioned in the document but from my point of view are
rather
> hidden as a reasoning for a recommendation. Therefore I would like to
see some
> further restructuring of the document.  This is not the same than the
original
> 'pitfalls' section was like because that section actually also tried to
give
> recommendation instead of just documenting things. However, that's
nothing that is for me
> to decide; maybe we should discuss this again in the next meeting
(because I think
> the mailing list discussion did not really led to a conclusion...?)...?
>
> Further, I have to say, I'm personally not super happy with sections 3-5.
> Even though the normative language was removed, it still tries to give
> recommendations instead of just summarizing what other docs hopefully
> already recommend. Further there seems to be still quite a bit of
redundancy
> which, if removed, would probably improve readability. At the same time
on other
> points the "recommendations" are still too high level to actually be really
> useful, from my point of view; e.g. see section 5 'Prerequisites for
network
> endpoints...": This basically says (in 3 bullets) that the used transport
> must implement ECN to use ECN. That's rather obvious for me. However, it
does
> not say more useful things like: it should still implement the ECN SYN
fallback as
> specified in RFC3168 because this cases actually still happens and that
e.g. Apple
> has a smaller RTO for SYNs with ECN which seems actual useful. Another
things
> we've just discovered while implementing this fallback for Linux was
that it is
> actually not clear which state TCP should be in if a second SYN without
ECN was
> send but a SYNACK with ECN is received. I think those things would be
interesting if
> recommendations are given. However, this might need additional expertise
from different
> people that can bring in more experience in implementing ECN and therefore
> I'm not sure if this doc should  give any recommendations.
>
GF: Interesting stuff, and happy to discuss this and I see we do need to
design things correctly (e.g., draft-kuehlewind-tcpm-ecn-fallbac), but are
you sure that operators or end users considering a roadmap to using ECN
needs to know how to design?

i.e., What do you hope for?: It could be that you would like you would
also like to make transport protocol design/deployment recommendations -
but if that is the case, we really didn't propose this when we brought the
document to the WG,

> That's another point that might need to be discuss at the next meeting
(or a
> separate discussion on this should be started at the mailing  list).
>
> All in all, if there is/would be consensus to move the document forward as
> it is, I'm in principle also fine with that expect that I'd would still
like to
> see a few changes in section 2.6/2.6.1. However, I personally think
there is more discussion
> needed to what the scope and purpose of this document is.
>
> Mirja
>
GF: This seems like a scope/milestone question - where we will need advice
from the Chairs.

Although, I agree design principles are useful to capture (if the IETF is
ready to do this), I still suggest this should be a separate document -
because I see the audience for good transport design are transport people
and network equipment/software manufacturers, rather than the present
focus encouraging other areas to look towards ECN deployment. Anyway,
depending on what is said we'll try and take this forward in an
appropriate direction.

((As someone from TSV,  I'm not at all sure that writing about how to
design ECN transports, should come from the IETF AQM WG, but that's
another detail to think about if people wish to do this.))

Gorry

>
> On 05.05.2015 20:49, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Active Queue Management and Packet
>> Scheduling Working Group of the IETF.
>>
>>          Title           : The Benefits of using Explicit Congestion
>> Notification (ECN)
>>          Authors         : Godred Fairhurst
>>                            Michael Welzl
>> 	Filename        : draft-ietf-aqm-ecn-benefits-04.txt
>> 	Pages           : 17
>> 	Date            : 2015-05-05
>>
>> Abstract:
>>     The goal of this document is to describe the potential benefits when
>>     applications use a transport that enables Explicit Congestion
>>     Notification (ECN).  The document outlines the principal gains in
>>     terms of increased throughput, reduced delay and other benefits when
>>     ECN is used over network paths that include equipment that supports
>>     ECN-marking.  It also describes methods that can help successful
>>     deployment of ECN.  It does not propose new algorithms to use ECN,
>>     nor does it describe the details of implementation of ECN in
>> endpoint
>>     devices (Internet hosts), routers or other network devices.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-ecn-benefits-04
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
>>
>
> --
> ------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Communication Systems Group
> Institute TIK, ETH Zürich
> Gloriastrasse 35, 8092 Zürich, Switzerland
>
> Room ETZ G93
> phone: [phone]
> email: [e-mail]
> ------------------------------------------
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>