The Benefits of Using Explicit Congestion Notification (ECN)
RFC 8087

Note: This ballot was opened for revision 06 and is now closed.

(Spencer Dawkins) Yes

Comment (2015-10-20 for -06)
No email
send info
In this text:

   The authors would like to thank the following people for their
   comments on prior versions of this document: Bob Briscoe, David
   Collier-Brown, Colin Perkins, Richard Scheffenegger, Dave Taht, Wes
   Eddy, Fred Baker, Mikael Abrahamsson, Mirja Kuehlewind, John Leslie,
   and other members of the AQM and TSV Working Groups.
   
At the risk of making the name redundant, the ack probably needs to go to the TSVWG working group.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2015-10-20 for -06)
No email
send info
- The discard of packets serves
   as a signal to the end-to-end transport that there may be congestion
   on the network path being used. 

Why not? 
   The discard of packets serves
   as a signal to the end-to-end transport that there is congestion
   on the network path being used. 



- Section 3.5.  Bleaching and Middlebox Requirements to deploy ECN

Sligthly confused by ECT(0) is different the zero codepoint

   When ECN-capable IP packets, marked as ECT(0) or ECT(1), are remarked
   to non-ECN-capable (i.e., the ECN field is set to zero codepoint),

   ...
   
   A network device must not change a packet with a CE mark to a zero
   codepoint, if the network device decides not to forward the packet
   with the CE-mark,

I had to look up https://tools.ietf.org/html/rfc3168

      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE

If you had one or two sentences to introduce the codepoints, that would avoid the confusion and would ease the readability.

And below is Dan Romascanu's OPS DIR review:
The following three comments are editorial in nature, triggered by difficulties in understanding some of the information (otherwise clearly presented):

 

1.       It would be useful to break the definition of ‘ECN-capable’ in two separate definitions for ‘ECN-capable packet’ and ‘ECN-capable network device’. It also would be good to copy or refer the definition of ECN codepoint from RFC 3168.

2.       Section 2.5 uses both CE-marking and ECN-marking terms. They are meant to be synonymous, so chosing one of them would make the text more clear

3.        Sections 4.3 and 5 uses the following phrase about endpoints – ‘it can … conservatively react to congestion’. Please explain what this means.

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2015-10-22 for -06)
No email
send info
The document fails to note that devices exist which still are or can be configured to use the tos byte as part of a hash key and therefore may induce extremely odd behavior including reordering or due to hashing to a stateful device, connection resets in the face of ecn capability signaling.

While we see these are rare they nevertheless still exist.

The canonical example of a network device doing this probably being junos enhanced hash key  which still supports this in contemporary code.

Barry Leiba No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection