[aqm] Benoit Claise's No Objection on draft-ietf-aqm-ecn-benefits-06: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-aqm-ecn-benefits-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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