Re: [tsvwg] Lars Eggert's No Objection on draft-ietf-tsvwg-l4s-arch-19: (with COMMENT)

[Bob Briscoe <[e-mail]>]

Lars,

Thx for your ballot positions and reviews of the three L4S drafts.
One response inline tagged [BB]. I'll deal with all the nits silently, 
as you suggest (for all 3 drafts) .


On 24/08/2022 13:00, Lars Eggert via Datatracker wrote:
> Lars Eggert has entered the following ballot position for
> draft-ietf-tsvwg-l4s-arch-19: 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 tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # GEN AD review of draft-ietf-tsvwg-l4s-arch-19
>
> CC @larseggert
>
> ## Comments
>
> ### "Abstract", paragraph 0
> ```
>    Abstract
> ```
> Does the abstract really need to be this long?

PREVIOUS:

    This document describes the L4S architecture, which enables Internet
    applications to achieve Low queuing Latency, Low Loss, and Scalable
    throughput (L4S).  The insight on which L4S is based is that the root
    cause of queuing delay is in the congestion controllers of senders,
    not in the queue itself.  With the L4S architecture all Internet
    applications could (but do not have to) transition away from
    congestion control algorithms that cause substantial queuing delay,
    to a new class of congestion controls that induce very little
    queuing, aided by explicit congestion signalling from the network.
    This new class of congestion controls can provide low latency for
    capacity-seeking flows, so applications can achieve both high
    bandwidth and low latency.

    The architecture primarily concerns incremental deployment.  It
    defines mechanisms that allow the new class of L4S congestion
    controls to coexist with 'Classic' congestion controls in a shared
    network.  These mechanisms aim to ensure that the latency and
    throughput performance using an L4S-compliant congestion controller
    is usually much better (and rarely worse) than performance would have
    been using a 'Classic' congestion controller, and that competing
    flows continuing to use 'Classic' controllers are typically not
    impacted by the presence of L4S.  These characteristics are important
    to encourage adoption of L4S congestion control algorithms and L4S
    compliant network elements.

    The L4S architecture consists of three components: network support to
    isolate L4S traffic from classic traffic; protocol features that
    allow network elements to identify L4S traffic; and host support for
    L4S congestion controls.  The protocol is defined separately as an
    experimental change to Explicit Congestion Notification (ECN).


PROPOSED (but not yet run past co-authors):

    This document describes the L4S architecture, which enables Internet
    applications to achieve Low queuing Latency, Low Loss, and Scalable
    throughput (L4S).  L4S is based on the insight that the root cause of
    queuing delay is in the capacity-seeking congestion controllers of
    senders, not in the queue itself.  With the L4S architecture all
    Internet applications could (but do not have to) transition away from
    congestion control algorithms that cause substantial queuing delay,
    to a new class of congestion controls that can seek capacity with
    very little queuing.  These are aided by a modified form of explicit
    congestion notification from the network, which is defined separately
    as an experimental change to ECN.  With this new architecture
    applications can have both low latency and high throughput.

    The architecture primarily concerns incremental deployment.  It
    defines mechanisms that allow the new class of L4S congestion
    controls to coexist with 'Classic' congestion controls in a shared
    network.  The aim is for L4S latency and throughput to be usually
    much better (and rarely worse), while typically not impacting Classic
    performance.


Thx again,


Bob

>
> ### Section 3, paragraph 1
> ```
>       Note: The following definitions are copied from the L4S ECN
>       spec [I-D.ietf-tsvwg-ecn-l4s-id] for convenience.  If there are
>       accidental differences, those in [I-D.ietf-tsvwg-ecn-l4s-id] take
>       precedence.
> ```
> Please instruct the RFC Editor to copy in the definitions from
> [I-D.ietf-tsvwg-ecn-l4s-id] during production and to remove the note above.
>
> ## Nits
>
> All comments below are about very minor potential issues that you may choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (viahttps://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
>
> ### Outdated references
>
> Reference `[RFC7540]` to `RFC7540`, which was obsoleted by `RFC9113` (this may
> be on purpose).
>
> Reference `[RFC4960]` to `RFC4960`, which was obsoleted by `RFC9260` (this may
> be on purpose).
>
> ### URLs
>
> These URLs in the document did not return content:
>
>   *https://www.bell-labs.com/usr/koen.de_schepper
>
> These URLs in the document can probably be converted to HTTPS:
>
>   *http://doi.acm.org/10.1145/2663716.2663730
>   *
>   http://www.cablelabs.com/wp-content/uploads/2013/11/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf
>   *http://bobbriscoe.net/  *http://dl.acm.org/citation.cfm?doid=2910017.2910633
>   *http://ee.lbl.gov/papers/congavoid.pdf  *http://www.it.uc3m.es
>
> ### Grammar/style
>
> #### Section 1, paragraph 8
> ```
> architecture is, rather than why. Finally Section 5 justifies why each eleme
>                                    ^^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Finally".
>
> #### Section 1.1, paragraph 1
> ```
> he document ends with the usual tail pieces, including extensive discussion
>                                  ^^^^^^^^^^^
> ```
> The word "tailpieces" is spelled as one word.
>
> #### Section 2, paragraph 2
> ```
> es in Section 5.1 and [RFC3649]. Therefore control of queuing and utilizatio
>                                   ^^^^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Therefore".
>
> #### Section 3, paragraph 4
> ```
> (e.g. DNS, VoIP, game sync datagrams, etc). Reno-friendly: The subset of Clas
>                                        ^^^
> ```
> A period is needed after the abbreviation "etc.".
>
> #### Section 3, paragraph 9
> ```
> ueue protection in this document. Otherwise the term rate policing is used.
>                                    ^^^^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Otherwise".
>
> #### Section 4.2, paragraph 8
> ```
> o ECT(1) packets [FQ_CoDel_Thresh]. Then if there is a flow of non-ECN or ECT
>                                      ^^^^
> ```
> Consider adding a comma here.
>
> #### Section 4.2, paragraph 11
> ```
>   equalize flow-rates (perhaps in a similar way to Approx Fair CoDel [AFCD],
>                                ^^^^^^^^^^^^^^^^
> ```
> Consider replacing this phrase with the adverb "similarly" to avoid wordiness.
>
> #### Section 4.2, paragraph 13
> ```
> nd QUIC transports, amongst others. Also an L4S variant of the RMCAT SCReAM c
>                                      ^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Also".
>
> #### Section 4.3, paragraph 2
> ```
>   more explicit signals can be applied so the queue can be kept short whatever
>                                       ^^^
> ```
> Use a comma before "so" if it connects two independent clauses (unless they are
> closely connected and short).
>
> #### Section 4.3, paragraph 3
> ```
> doesn't know the round trip times of any of the flows. So if the network is
>                                    ^^^^^^^^^
> ```
> Consider simply using "of" instead.
>
> #### Section 4.3, paragraph 3
> ```
> e Classic approach), it has to assume a worst case RTT, otherwise long RTT fl
>                                        ^
> ```
> Use "the" before the superlative.
>
> #### Section 5.1, paragraph 5
> ```
> s the recovery time is 24.3 s. In contrast a scalable congestion control like
>                                    ^^^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "contrast".
>
> #### Section 5.2, paragraph 6
> ```
> ll treats ECN and drop the same. Therefore ABE exploits any lower queuing de
>                                   ^^^^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Therefore".
>
> #### Section 5.2, paragraph 6
> ```
> rt-up phase. L4S complements BBR. Indeed BBRv2 can use L4S ECN where availab
>                                    ^^^^^^
> ```
> A comma may be missing after the conjunctive/linking adverb "Indeed".
>
> #### Section 5.2, paragraph 11
> ```
> displayed a viewport taken from a 360 degree camera in a racing car. The user
>                                    ^^^^^^^^^^
> ```
> When "360-degree" is used as a modifier, it is usually spelled with a hyphen.
>
> #### Section 5.2, paragraph 17
> ```
>   packets while building each burst. WiFi, PON and cable all involve such pack
>                                      ^^^^
> ```
> Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
> Alliance.).
>
> #### Section 6.1, paragraph 1
> ```
> ifically: * Radio links (cellular, WiFi, satellite) that are distant from th
>                                     ^^^^
> ```
> Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
> Alliance.).
>
> #### Section 6.2, paragraph 12
> ```
> ould often next be needed where the WiFi links in a home sometimes become th
>                                      ^^^^
> ```
> Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
> Alliance.).
>
> #### Section 6.4.1, paragraph 6
> ```
> stream bottlenecks in one go ---whether or not all the origin servers were up
>                                  ^^^^^^^^^^^^^^
> ```
> Consider shortening this phrase to just "whether". It is correct though if you
> mean "regardless of whether".
>
> #### Section 6.4.2, paragraph 1
> ```
> ll clients that support AccECN (whether or not they support L4S as well). And
>                                  ^^^^^^^^^^^^^^
> ```
> Consider shortening this phrase to just "whether". It is correct though if you
> mean "regardless of whether".
>
> #### Section 6.4.2, paragraph 14
> ```
>   how operators can use an additional local classifiers (see section 5.4 of th
>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ```
> The plural noun "classifiers" cannot be used with the article "an". Did you
> mean "an additional local classifier" or "additional local classifiers"?
>
> #### Section 6.4.3, paragraph 8
> ```
> yments of new bursty malware, in a similar way to how traffic from flooding
>                                ^^^^^^^^^^^^^^^^
> ```
> Consider replacing this phrase with the adverb "similarly" to avoid wordiness.
>
> #### Section 6.4.4, paragraph 1
> ```
>   distributed across a subnet inter-communicating using lower layer control me
>                               ^^^^^^^^^^^^^^^^^^^
> ```
> This word is normally spelled as one.
>
> #### Section 8.1, paragraph 1
> ```
> re, which works without them (in a similar way to how the Internet works wit
>                                ^^^^^^^^^^^^^^^^
> ```
> Consider replacing this phrase with the adverb "similarly" to avoid wordiness.
>
> #### Section 8.2, paragraph 7
> ```
> TCP BBR v2 Alpha/Preview Release", github repository; Linux congestion contr
>                                     ^^^^^^
> ```
> The official name of this software platform is spelled GitHub.
>
> #### Section 9, paragraph 7
> ```
> net: Understanding and Solutions", Masters Thesis; Karlstad Uni, Dept of Math
>                                     ^^^^^^^
> ```
> For an academic degree, use "Master's".
>
> #### Section 9, paragraph 28
> ```
> [SCReAM] Johansson, I., "SCReAM", github repository; , <https://github.com/Er
>                                    ^^^^^^
> ```
> The official name of this software platform is spelled GitHub.
>
> #### Section 9, paragraph 29
> ```
> ng for 4G in a network simulator", Masters Thesis, Uni Oslo , June 2019. Ack
>                                     ^^^^^^^
> ```
> For an academic degree, use "Master's".
>
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].
>
> [ICMF]:https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]:https://github.com/mnot/ietf-comments
> [IRT]:https://github.com/larseggert/ietf-reviewtool
>
>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/