The Benefits of Using Explicit Congestion Notification (ECN)
draft-ietf-aqm-ecn-benefits-08

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

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.