ietf-wg-mops / draft-ietf-mops-streaming-opcons

drafts for the mops IETF working group
Other
5 stars 4 forks source link

Lars Eggert Ballot Comments #154

Closed SpencerDawkins closed 2 years ago

SpencerDawkins commented 2 years ago

From @larseggert

Comments

Section 6.3, paragraph 0

  6.3.  QUIC and Its Behavior

I'm surprised this section doesn't refer to draft-ietf-quic-manageability? That document discusses some of the same (and related) issues.

Section 6.3, paragraph 1

     Although QUIC provides an alternative to the TCP and UDP transport
     protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
     Section 7.1, the QUIC protocol encrypts almost all of its transport
     parameters, and all of its payload, so any intermediaries that
     network operators may be using to troubleshoot HTTP streaming media
     performance issues, perform analytics, or even intercept exchanges in
     current applications will not work for QUIC-based applications
     without making changes to their networks.  Section 7 describes the
     implications of media encryption in more detail.

"Transport parameter" is a QUIC-specific term to describe connection-level settings that are negotiated during the handshake. I think this paragraph - and others that mention transport parameters in this document - mean to talk about the broader concept of "connection metadata". I would suggest not overloading the QUIC "transport parameter" term in this way.

Inclusive language

Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance:

  • Terms his and he; alternatives might be they, them, their
  • Term traditional; alternatives might be classic, classical, common, conventional, customary, fixed, habitual, historic, long-established, popular, prescribed, regular, rooted, time-honored, universal, widely used, widespread

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 (via https://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.

Typos

Section 3.2, paragraph 1

-    the contraints on bandwidth at various points in the network.  This
-    analysis is necessary because media servers may react to bandwith
+    the constraints on bandwidth at various points in the network.  This
+           +
+    analysis is necessary because media servers may react to bandwidth
+                                                                   +

Section 3.2, paragraph 7

-       transport-level loss is occuring, but
+       transport-level loss is occurring, but
+                                    +

Section 5.4, paragraph 3

-    (herafter referred to as "ads").
+    (hereafter referred to as "ads").
+        +

Section 5.5.3, paragraph 1

-    hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
+    hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have
+                                                          +

Section 6.1, paragraph 3

-    In contrast to adaptive segmented delivery over a reliable tansport
+    In contrast to adaptive segmented delivery over a reliable transport
+                                                                +

Section 6.3, paragraph 5

-    application until the lost packet is retransmitted, allowing in-order
-                                      ^    ^^^^^^ ^^
+    application until a retransmission of the lost packet has been received, allowing in-order
+                      ++++++++++++++++++++                ^^ +++++   ^^ ^

Section 6.3, paragraph 7

-    As noted in Section 6.2, there is an increasing interest in transport
-                                                                 ^^ -----
-    protocol behaviors that respond to delay measurements, instead of
-    ^ ----   --- ^^
-    responding to packet loss.  These behaviors may deliver improved user
-                                      --- ^^
+    As noted in Section 6.2, there is an increasing interest in congestion
+                                                                ++++++ ^^
+    control algorithms that respond to delay measurements, instead of
+    ^^^^     ^^  ++++
+    responding to packet loss.  These algorithms may deliver improved user
+                                       ^^  ++++

Section 6.3, paragraph 7

-    agility, and [RFC9002] defines a basic algorithm with transport
-                                                    ---------------
-    behavior that is roughly similar to TCP NewReno [RFC6582].  However,
-   ---------
+    agility, and [RFC9002] defines a basic congestion control algorithm
+                                           +++++++++++++++++++

Section 7.2, paragraph 9

-    benefitted from this intervention a media streaming operator
-          -

Section 7.3, paragraph 4

-    monitoring of IETF protocols to continue for the forseeable future.
+    monitoring of IETF protocols to continue for the foreseeable future.
+                                                        +

Duplicate references

Duplicate informative references to: https://datatracker.ietf.org/meeting/interim-2020-mops-01/materials/slides-interim-2020-mops-01-sessa-april-15-2020-mops-interim-an-update-on-streaming-video-alliance.

Outdated references

Reference [RFC2001] to RFC2001, which was obsoleted by RFC2581 (this may be on purpose).

Grammar/style

Section 1, paragraph 12

Discussion This document is in the Github repository at: https://github.com/
                                   ^^^^^^

The official name of this software platform is spelled with a capital "H".

Section 3.6, paragraph 1

"throttle" these transfers in order to to mitigate the load that these hosts
                                    ^^^^^

Possible typo: you repeated a word.

Section 3.6, paragraph 3

a [Mishra] reported that after the CoViD-19 pandemic broke out in early 2020
                                   ^^^^^^^^

Did you mean "COVID-19" or the alternative spelling "Covid-19" (= coronavirus)?

Section 3.6, paragraph 4

ffic up 36% over an average day (pre COVID-19)}. We note that other operators
                                 ^^^^^^^^^^^^

The word "pre-COVID-19" is spelled with a hyphen.

Section 4.1, paragraph 2

o, and some tradeoffs may be necessary relative to what is feasible in a hig
                             ^^^^^^^^^^^^^^^^^^

In this context, the adverb seems more correct than the adjective "necessary".

Section 4.1, paragraph 5

rations. However, shorter segments means more frequent intra-coded frames an
                                   ^^^^^

It seems that the correct verb form here is "mean".

Section 4.2, paragraph 3

ecessary to support low-latency live streaming. This level of latency can typ
                                ^^^^^^^^^^^^^^

This expression is normally spelled as one or with a hyphen.

Section 5.3, paragraph 1

oth content and ads) are able to be accessed quickly. The less targeted, the
                                 ^^^^^^^^^^^

Avoid the passive voice after "to be able to".

Section 6.3, paragraph 12

ransport parameters itself, with the exception of a few invariant header fie
                            ^^^^^^^^^^^^^^^^^^^^^

Consider using "except" or "except for".

Section 7.2, paragraph 5

Reading and References The Media Operations community maintains a list of ref
                                 ^^^^^^^^^^

An apostrophe may be missing.

Section 7.2, paragraph 8

C., Zimmermann, R., and A. Bentaleb et al, "A Survey on Bitrate Adaptation Sc
                                    ^^^^^

A period is misplaced or missing. (Also in other references.)

Notes

This review is in the "IETF Comments" Markdown format, You can use the ietf-comments tool to automatically convert this review into individual GitHub issues. Review generated by the ietf-reviewtool.

SpencerDawkins commented 2 years ago

@larseggert - thank you for this review. You caught a lot more things than I was hoping were still in there. :grinning:

acbegen commented 2 years ago

PR #167 should address these issues (and more).

SpencerDawkins commented 2 years ago

Agree with @acbegen that this fixed lots of stuff. I'd like to leave it open so we can run this tool again after addressing more issues.