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

From: "Benoit Claise" <[email-masked]>
Date: Tue, 20 Oct 2015 07:57:33 -0700

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.

---

From: [email-masked]
Date: Tue, 20 Oct 2015 17:01:57 +0100

Thanks for the feedback.

Gorry

> https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
Because a loss can also be due to other reasons than congestion,
it would help to explain this. I will add.

>    to non-ECN-capable (i.e., the ECN field is set to zero codepoint),
OK, We'll add - probably need to explain the numerical value for non-ECT,
etc.

> I had to look up https://tools.ietf.org/html/rfc3168
Understood, will update.

> meant to be synonymous, so chosing one of them would make the text more
All should be "CE-marked", will change.

> ‘it can … conservatively react to congestion’. Please explain what
> this means.
>
I'll discuss with my co-author on how to add more text here.

Gorry

---

From: [email-masked]
Date: Tue, 20 Oct 2015 17:02:04 +0100

Thanks for the feedback.

Gorry

Understood, will update.

Gorry