Skip to main content

Last Call Review of draft-ietf-mops-streaming-opcons-10
review-ietf-mops-streaming-opcons-10-tsvart-lc-scharf-2022-04-29-00

Request Review of draft-ietf-mops-streaming-opcons
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2022-05-06
Requested 2022-04-22
Requested by Éric Vyncke
Authors Jake Holland , Ali C. Begen , Spencer Dawkins
I-D last updated 2022-04-29
Completed reviews Intdir Last Call review of -10 by Tommy Pauly (diff)
Opsdir Last Call review of -10 by Linda Dunbar (diff)
Tsvart Last Call review of -10 by Michael Scharf (diff)
Artart Last Call review of -10 by Valery Smyslov (diff)
Secdir Last Call review of -10 by Nancy Cam-Winget (diff)
Comments
This is the first MOPS WG document and it has interesting contents for transport, Internet, ART, and operations. So, I will appreciate a last call review by your directorate.

Regards

-éric
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-mops-streaming-opcons by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/TsoCdajq17FsRy8peRQLc_-vi8Y
Reviewed revision 10 (document currently at 12)
Result Ready w/issues
Completed 2022-04-29
review-ietf-mops-streaming-opcons-10-tsvart-lc-scharf-2022-04-29-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This informational document surveys network and transport protocol issues that
affect quality of experience for streaming applications, in particular video.

The overview covers many topics across different technologies. Readers may only
be familiar with a subset of these topics and could therefore learn quite a bit
from this kind of tutorial.

Nonetheless, it remains somewhat unclear what the actual objective of some of
the text is. For some topics, quite a bit of technical background is provided,
but the discussion is not really comprehensive. In many sections, the document
neither derives technical challenges, nor system/protocol requirements, nor
practical usage guidance. It is just a kind of tutorial. Quite a bit of text
also presents ongoing IETF work, and an RFC with this scope may thus get
outdated soon.

Section 6.2 deals with topics owned by TCPM. In similar past documents, I have
asked for a TCPM presentation prior to an IETF last call in order to ensure
that owners of running code are in the loop. I believe this strategy has worked
well in the past.

Having said this, as TSV-ART reviewer I don't strongly disagree with a
publication. All these issues may just be OK for an informational RFC.

Some more specific comments:

* Section 3.2.1.  Recognizing Changes from an Expected Baseline

This section apparently assumes relatively static path properties, e.g., fixed
network connectivity. It would be more useful to analyze the impact of Wifi and
4G/5G networks in one place. Some of this follows later in sections 3.2.1 and
5.5.3. Yet, the split between these three sections is unclear. Having a
discussion about today's Internet path characteristics and the dynamics at one
place could be more useful.

The text could also better distinguish between what matters to endpoints and
considerations relevant only for middleboxes (such as passive monitors).

* Section 3.3 Path Requirements

The statement "to find the bandwidth requirements for a router on the delivery
path" may assume that the bottleneck on the path will be routers. Yet, on a
path the bottlenecks could also be a link layer device (e.g., an Ethernet
Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also
explains that issue. A better wording may be "to find the bandwidth
requirements for a delivery path".

* Section 3.6.  Unpredictable Usage Profiles / Section 3.7.  Extremely
Unpredictable Usage Profiles

I am not fully convinced by the distinction between "unpredictable" and
"extremely unpredictable". To me, these two sections could be merged and maybe
also be shortened. More specifically, Section 3.7 lists a lot of statistics
from the past. What is IMHO a bit missing in Section 3.7 are actual operational
considerations. For instance, are there any lessons learnt for the future? Note
that Section 3.6 has a reasonable conclusion at the end.

* Section 4.  Latency Considerations and Section 4.1.  Ultra Low-Latency

I am surprised by the definition "ultra low-latency (less than 1 second)", as
well as some of the other numbers. For other real-time communication use cases,
"ultra low-latency" would probably imply a latency requirement of the order of
*one millisecond*. For instance, isochronous traffic for motion control in
industrial networks may require a latency of 1 ms, and such "ultra-low latency"
requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology
in this section should be better explained to readers dealing with networked
systems with much harder latency requirements. And a reference should be added
for these definitions in the context of video streaming.

* Section 5.5.2 Head-of-Line Blocking

If Head-of-Line Blocking is indeed a relevant operational problem, it would be
useful to add a corresponding reference (e.g., with measurements).

* Section 5.5.3.  Wide and Rapid Variation in Path Capacity

The statement "As many end devices have moved to wireless connectivity for the
final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged
from radio interference and signal strength effects." could be moved to earlier
parts of the document. Quite a bit of new computers apparently only have Wifi
connectivity and no Ethernet port, i.e., Wifi may just be their default. Also,
wireless may not only be used on the last hop, for instance in meshed setups.
This may make the problem even harder.

* Section 6.  Evolution of Transport Protocols and Transport Protocol Behaviors

I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant
distinction. What may actually matter are the transport services provided by
the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the
INTDIR review.

* Section 6.1.  UDP and Its Behavior

UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does
encrypted tunneling really have no operational impact on streaming apps other
than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the
like.)

* Section 6.2.  TCP and Its Behavior

This text should IMHO be presented and be discussed in TCPM. Personally, I am
not convinced that this document is a good place for discussing the long
history of TCP congestion control. If the objective of the document is to
provide a tutorial, IMHO it would be more useful to briefly explain the
state-of-the-art in year 2022. Some further specific comments on TCP congestion
control:

- It is surprising that RFC 5681 is not referenced.

- 793bis has normative statements regarding congestion control, and most stacks
are compatible to what is written in 793bis. Several operating systems use
CUBIC by default and support standard Reno.

- Another general good reference for TCP standards is RFC 7414.

- Does ECN, DCTCP, etc. really not matter at all, for instance, if a data
center hosts video playout servers?

* Section 6.3.  QUIC and Its Behavior

As already noted, the discussion about head-of-line-blocking would really
benefit from backing by a reference.

* Section 7. Streaming Encrypted Media

As far as I know, streaming users sometimes use encrypted tunnels such as
OpenVPN or WireGuard (or IPsec) to access video content. I may miss something,
but it is unclear to me how that fits into the categories presented in Section
7.