Subject: [tsvwg] Editorial review of draft-ietf-tsvwg-aqm-dualq-coupled-08

From: David Pullen <[email-masked]>
Date: Tue, 11 Dec 2018 15:29:53 -0500

Hi Bob,

Apologies if I'm doing this wrong, this is my first time providing input on
an IETF draft.

I am reviewing the draft-ietf-tsvwg-aqm-dualq-coupled-08 document (
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08). These
are purely editorial comments/suggestions. I will send separate emails for
technical discussions.

In Section 2.1:

*   smoothing in the network, because it delays all signals for a worst- *I
recommend changing "it delays" to "smoothing delays". At first glance, "it"
seems to refer to L4S.

*   themselves, so they expect the network to generate ECN marks with a*

I recommend changing "so" to "thus"; minor improvement in readability.

In Section 2.2:

*   and it is scheduled with priority over Classic.  Priority is*
I recommend changing "over Classic" to "over Classic traffic".

In Section 2.3:

*   additional packet types into the L queue, that are deemed not to risk*
I recommend changing "that are" to "which are".

*   Note that the mechanism only reads these classifiers, it MUST NOT re-*
Should "classifiers" be "identifiers"?

In Section 2.4:

*   Both AQMs regulate their queue in units of time not bytes.  As*
I recommend changing "not bytes" to "rather than bytes".

*   AQMs, as long as the normative requirements (those expressed in
  capitals) in Section 2.5 are observed.*
Is it necessary to state "(those expressed in capitals)"? Isn't the meaning
of "normative requirements" defined previously?

In Section 2.5.1:

*   flow rates at any times when all flows are Classic or all L4S, and it*
I recommend changing "all L4S" to "all flows are L4S".

In Section 2.5.2:

*   DualQ Couple AQM is to enable deployment and coexistence of scalable*

I recommend changing "Couple" to "Coupled".

Thanks,
  - Dave

David Pullen
Distinguished Engineer  |  Wired Networking, Cable Modems
Broadcom

office: 678.475.3143  |  mobile: 678.477.4108  |  fax: 770.232.0211
4385 River Green Parkway  |  Duluth, GA 30096
[email-masked]   |   broadcom.com

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 13 Dec 2018 17:31:48 +0000

David,

You're doing this perfectly right. Thank you for catching all these.

Where I've not commented below, I've taken your suggestion as is. 
Otherwise, I've noted the text I've used instead inline (tagged [BB]), 
'cos sometimes shining your spotlight on a sentence made other problems 
jump out at me.

I have edited our local copy on bitbucket, but I won't post these edits 
as a new draft yet, given we're expecting further comments shortly.

On 11/12/2018 20:29, David Pullen wrote:
> Hi Bob,
>
> Apologies if I'm doing this wrong, this is my first time providing 
> input on an IETF draft.
>
> I am reviewing the draft-ietf-tsvwg-aqm-dualq-coupled-08 document 
> (https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08). 
> These are purely editorial comments/suggestions. I will send separate 
> emails for technical discussions.
>
> In Section 2.1:
>
> *
>
> *smoothing in the network, because it delays all signals for a worst-*
>
> *I recommend changing "it delays" to "smoothing delays". At first 
> glance, "it" seems to refer to L4S.
>
> *
>   and it is scheduled with priority over Classic.  Priority is
>
> *
[BB] I can see the readability problem but I've changed this to '...over 
the Classic queue' to match the subject of the sentence, and to avoid 
repeating the end of the subsequent sentence. Both sentences now read as:

     Therefore a separate queue is provided for L4S traffic, and it is 
scheduled with priority over the Classic queue. Priority is conditional 
to prevent starvation of Classic traffic.
mechanism

>
> In Section 2.3:
>
> *
>
>   additional packet types into the L queue, that are deemed not to risk
>
> *
[BB] On reflection, I've removed the comma, but kept "that are..." 
because the sub-clause is not incidental to the intended sense. To 
choose between "which" over "that", I test whether removing the clause 
is optional to the intended sense. I also changed the sentence from 
passive to active, to reduce ambiguity. The full sentence now reads:

     In addition, an operator could use other identifiers to classify 
certain additional packet types into the L queue that it deems will not 
risk harm to the L4S service.

>
> *
>
>   Note that the mechanism only reads these classifiers, it MUST NOT re-
>
> *
> *
>   Both AQMs regulate their queue in units of time not bytes.  As
>
> *
> *
>   AQMs, as long as the normative requirements (those expressed in
>
>   capitals) in Section 2.5 are observed.
>
> *
> Is it necessary to state "(those expressed in capitals)"? Isn't the 
> meaning of "normative requirements" defined previously?
[BB] Actually, the template IETF text about use of capitalized terms 
doesn't mention the word "normative". So I thought I had better explain 
what I meant by "normative" (e.g. even after many years of IETF 
activity, I had not really understood what "normative" meant).

>
> In Section 2.5.1:
>
> *
>
>   flow rates at any times when all flows are Classic or all L4S, and it
>
> *
[BB] Thank you.

Bob

>
> David PullenDistinguished Engineer  |  Wired Networking, Cable 
> ModemsBroadcomoffice:678.475.3143  | mobile:678.477.4108  | 
> fax:770.232.02114385 River Green Parkway  |  Duluth, GA 
> [email-masked] <mailto:[email-masked]>   | 
> broadcom.com <http://broadcom.com>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: David Pullen <[email-masked]>
Date: Thu, 13 Dec 2018 16:24:09 -0500

Hi Bob,

Thanks for getting back to me. Your responses and suggested updates look
reasonable to me.

I will follow up with technical comments in future emails (hopefully
Friday).

Thanks,
  - Dave

David Pullen

On Thu, Dec 13, 2018 at 12:31 PM Bob Briscoe <[email-masked]> wrote:

> Otherwise, I've noted the text I've used instead inline (tagged [BB]), 'cos
> sometimes shining your spotlight on a sentence made other problems jump out
> at me.
>
> I have edited our local copy on bitbucket, but I won't post these edits as
> a new draft yet, given we're expecting further comments shortly.
>
>
> Apologies if I'm doing this wrong, this is my first time providing input
> on an IETF draft.
>
> *   and it is scheduled with priority over Classic.  Priority is *
> scheduled with priority over the Classic queue. Priority is conditional to
> prevent starvation of Classic traffic.
> mechanism
>
>
> In Section 2.3:
>
> *   additional packet types into the L queue, that are deemed not to risk *
> [BB] On reflection, I've removed the comma, but kept "that are..." because
> the sub-clause is not incidental to the intended sense. To choose between
> "which" over "that", I test whether removing the clause is optional to the
> intended sense. I also changed the sentence from passive to active, to
> reduce ambiguity. The full sentence now reads:
>
> *   Note that the mechanism only reads these classifiers, it MUST NOT re- *
> *   Both AQMs regulate their queue in units of time not bytes.  As *
>   capitals) in Section 2.5 are observed. *
> what I meant by "normative" (e.g. even after many years of IETF activity, I
> had not really understood what "normative" meant).
>
>
>
> In Section 2.5.1:
>
> *   flow rates at any times when all flows are Classic or all L4S, and it *
> David Pullen Distinguished Engineer  |  Wired Networking, Cable Modems
> Broadcom office: 678.475.3143  |  mobile: 678.477.4108  |  fax:
> 770.232.0211 4385 River Green Parkway  |  Duluth, GA 30096

---

From: David Pullen <[email-masked]>
Date: Mon, 17 Dec 2018 14:17:54 -0500

Hi Bob,

I appear to have overlooked an editorial comment. In Appendix B:

requires only one parameter, the scaling, not three.  The diadvantage

Please correct the spelling of the highlighted word to "disadvantage".

Thanks,
  - Dave

David Pullen

On Thu, Dec 13, 2018 at 4:24 PM David Pullen <[email-masked]>
wrote:

>> https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-08).
>> because the sub-clause is not incidental to the intended sense. To choose
>> between "which" over "that", I test whether removing the clause is optional
>> to the intended sense. I also changed the sentence from passive to active,
>> to reduce ambiguity. The full sentence now reads:
>>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 17 Dec 2018 19:30:17 +0000

David, Thx. Corrected (in local copy).
bob

On 17/12/2018 19:17, David Pullen wrote:
> On Thu, Dec 13, 2018 at 4:24 PM David Pullen 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Bob,
>
>     Thanks for getting back to me. Your responses and suggested
>     updates look reasonable to me.
>
>     I will follow up with technical comments in future emails
>     (hopefully Friday).
>
>     Thanks,
>       - Dave
>
>     [email-masked] <mailto:[email-masked]>
>       | broadcom.com <http://broadcom.com>
>
>
>
>     On Thu, Dec 13, 2018 at 12:31 PM Bob Briscoe <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         David,
>
>         Where I've not commented below, I've taken your suggestion as
>         is. Otherwise, I've noted the text I've used instead inline
>         (tagged [BB]), 'cos sometimes shining your spotlight on a
>         sentence made other problems jump out at me.
>
>         I have edited our local copy on bitbucket, but I won't post
>         these edits as a new draft yet, given we're expecting further
>         comments shortly.
>
>
>>         Apologies if I'm doing this wrong, this is my first time
>>         providing input on an IETF draft.
>>
>>         These are purely editorial comments/suggestions. I will send
>>         separate emails for technical discussions.
>>
>>         In Section 2.1:
>>
>>         *
>>
>>         *I recommend changing "it delays" to "smoothing delays". At
>>         first glance, "it" seems to refer to L4S.
>>
>         [BB] I can see the readability problem but I've changed this
>         to '...over the Classic queue' to match the subject of the
>         sentence, and to avoid repeating the end of the subsequent
>         sentence. Both sentences now read as:
>
>             Therefore a separate queue is provided for L4S traffic,
>         and it is scheduled with priority over the Classic queue.
>         Priority is conditional to prevent starvation of Classic traffic.
>         mechanism
>
>>
>>         In Section 2.3:
>>
>>         *
>>
>         [BB] On reflection, I've removed the comma, but kept "that
>         are..." because the sub-clause is not incidental to the
>         intended sense. To choose between "which" over "that", I test
>         whether removing the clause is optional to the intended sense.
>         I also changed the sentence from passive to active, to reduce
>         ambiguity. The full sentence now reads:
>
>             In addition, an operator could use other identifiers to
>         classify certain additional packet types into the L queue that
>         it deems will not risk harm to the L4S service.
>
>
>>
>>         *
>>
>>         Is it necessary to state "(those expressed in capitals)"?
>>         Isn't the meaning of "normative requirements" defined previously?
>         [BB] Actually, the template IETF text about use of capitalized
>         terms doesn't mention the word "normative". So I thought I had
>         better explain what I meant by "normative" (e.g. even after
>         many years of IETF activity, I had not really understood what
>         "normative" meant).
>
>
>>
>>         In Section 2.5.1:
>>
>>         *
>>
>>         David PullenDistinguished Engineer  |  Wired Networking,
>>         Cable ModemsBroadcomoffice:678.475.3143  |
>>         mobile:678.477.4108  | fax:770.232.02114385 River Green
>>         Parkway  |  Duluth, GA [email-masked]
>>         <mailto:[email-masked]>   | broadcom.com
>>         <http://broadcom.com>
>>
>
>         -- 
>         Bob Briscoehttp://bobbriscoe.net/
>