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

[Mirja Kühlewind <[e-mail]>]

Hi Gorry,

I think my main issues can be resolves with some smaller changes or additions/removals. However, I still think that this document should not give any recommendation what a network node or the transport must or should do. The group has to decided on this, but I guess this would be a large change in the sections 3-5.

See below. 

>> 
>> 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.
> 

Not sure what you mean by ‚end-to-end users of the service‘. For me the transport protocol or the congestion control of the transport is the user of the ECN signal. And here we should be careful what we say.


> 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.

That helps a little buts still doesn’t make me completely happy. The main problem is co-existence with current traffic. And this probably requires both the congestion control as well as the AQM to be updated together and makes the problem more complex. While the current text more reads like, please go ahead and design a new congestion control OR AQM but be careful… don’t think that’s enough.

Further it is not only this one sentence; there are more sentences in these paragraph which say very similar things.

What about basically simply removing these sentences:

OLD:
"2.6.  Opportunities for new Transport Mechanisms

   Loss is regarded as the standard signal from a network device
   experiencing congestion.  In contrast, CE-marked packets carry an
   indication that network queues are filling, without incurring loss.
   This introduces the possibility to provide richer feedback (more
   frequent and fine-grained indications) to transports.  This could
   utilise new thresholds and algorithms for ECN-marking.  ECN therefore
   provides a mechanism that can benefit evolution of transport
   protocols.


2.6.1.  Benefits from other forms of ECN-Marking/Reactions

   ECN requires a definition of both how network devices CE-mark packets
   and how applications/transports react to reception of these CE-marked
   packets.  ECN-capable receiving endpoints therefore need to provide
   feedback indicating that CE-marks were received.[RFC3168]provides a
   method that signals once each round trip time that CE-marked packets
   have been received.  An endpoint may provide more detailed feedback
   describing the set of received ECN codepoints using Accurate ECN
   Feedback [ID.Acc.ECN].  This can provide more information to a
   congestion control mechanism at the sending endpoint.

   Loss and CE-marking are both used as an indication for congestion.
   However, while the amount of feedback that is provided by loss ought
   naturally to be minimized, this is not the case for ECN.  With ECN, a
   network device could provide richer and more frequent feedback on its
   congestion state.  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.

   Precise feedback about the number of packet marks encountered is
   supported by the Real Time Protocol (RTP) when used over UDP
   [RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc.ECN].

   Benefit has been noted when packets are CE-marked earlier using an
   instantaneous queue, and if the receiver provides feedback about the
   number of packet marks encountered, an improved sender behavior has
   been shown to be possible (e.g, Datacenter TCP (DCTCP) [AL1]).
   DCTCP is targeted at confined environments such as a datacenter.  It
   is currently unknown whether or how such behaviour could be safely
   introduced into the Internet.“

NEW:
"2.6.  Opportunities for new Transport Mechanisms

   Loss and CE-marking are both used as an indication for congestion.
   However, while the amount of feedback that is provided by loss ought
   naturally to be minimized, this is not the case for ECN. In contrast, 
   CE-marked packets carry an indication that network queues are filling, 
   without incurring loss. This introduces the possibility to provide 
   richer feedback (more frequent and fine-grained indications) on the 
   congestion state to transports. 

   Unfortunately, the current specification of the feedback mechanism 
   in ECN from the receiver to the sender [RFC3168] provides signals 
   only once each round trip time that CE-marked packets have been 
   received. The receiving endpoint may provide more detailed feedback
   describing the set of received ECN codepoints using Accurate ECN
   Feedback [ID.Acc.ECN].  This can provide more information to a
   congestion control mechanism at the sending endpoint.

   Precise feedback about the number of packet marks encountered is
   supported by the Real Time Protocol (RTP) when used over UDP
   [RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc.ECN].

   Note that even if richer feedback is provided, ECN requires a 
   definition of both how network devices CE-mark packets
   and how the control loop in the application/transport reacts to 
   reception of these CE-marked packets. 

   An control mechanism, where CE marks are sent early based the 
   instantaneous queue length used a more fine-graind sender behavior,
   has been shown by Datacenter TCP (DCTCP) [AL1] to be possible and 
   beneficial to provide improved latency. As DCTCP require changes of 
   all end hosts and network nodes, DCTCP is targeted at confined 
   environments such as a datacenter.  It is currently unknown 
   whether or how such behavior could be safely introduced into 
   the Internet.“

And maybe also remove the following sentence in section 3:

"There is opportunity to design an AQM method for ECN that differs
   from one designed to drop packets (e.g., Random Early Detection uses
   a smoothed queue length because it was designed for loss and a
   congestion control that halves its sending rate on congestion)
   [ID.RFC2309.bis]. "


> 
>> 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, …


Okay.


> 
> 
>> 
>> 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.“

I’m questioning if what the abstract states is the right scope of this document.

Further this document still gives recommendation which is not reflected in the abstract.
And I don’t really think that the document „describes methods that can help successful deployment of ECN“ because I don’t really see any methods in this doc...


> 
>> 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,

No, these are no points on protocol design. These are things that are good to know if you want to implement ECN as specified in RFC3168. Maybe something like lessons learnt from implementation and measurement. 

As I said, I personally have the feeling that the recommendations given in this document are not super helpful, while other recommendation that are missing could actually be more helpful. But that would rather be a different document, therefore I’d proposed to remove all recommendation from this document which would mean that a) a to of things would be removed from sections 3-5  and b) only those things remain which list problem (without giving recommendations).

And I say this again, from point of view the problem with the previous ‚pitfalls‘ section was that this section gave recommendation. However you (only) removed the word ‚pitfalls‘ but left all the recommendation in the document. I’d say the other way around would have been better… 

> 
>> 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.

Yes, I agree, this should be a different document. I also agree that we might be not fully ready yet to provide these design principles (not sure this is the right term here). Therefore I still recommend to remove any recommendation from this doc. However this would mean to remove quite a lot stuff in sections 3-5 (and potentially merge them into only one or two sections). 

> 
> ((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.))

As the document states this correctly, it’s not enough to only change the transport/congestion control. We probably need to change both congestion control and AQM. Therefore this is probably a cross-wg thing between AQM and TCPM/TSVWG.

Mirja


> 
> 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
>>