Skip to main content

Last Call Review of draft-ietf-mops-ar-use-case-15
review-ietf-mops-ar-use-case-15-tsvart-lc-eddy-2024-03-25-00

Request Review of draft-ietf-mops-ar-use-case
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-04-02
Requested 2024-03-19
Authors Renan Krishna , Akbar Rahman
I-D last updated 2024-03-25
Completed reviews Tsvart Last Call review of -15 by Wesley Eddy
Artart Last Call review of -15 by Paul Kyzivat
Assignment Reviewer Wesley Eddy
State Completed
Request Last Call review on draft-ietf-mops-ar-use-case by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/87culjkm6tXMkx-cXEsYGDt060k
Reviewed revision 15
Result Ready w/issues
Completed 2024-03-25
review-ietf-mops-ar-use-case-15-tsvart-lc-eddy-2024-03-25-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.

The document reads well and is easy to understand.  It is a nice overview of
the use case that it describes, and does a great job explaining terminology and
providing relevant resources.

My only issue with the present revision, is that in reviewing from a TSVART
perspective, I see that there is discussion of latency and bandwidth needs, but
there does not seem to be much discussion of what the transport or other
protocols need to do to facilitate the use case.  For instance, are there
multiple independent streams (for audio, video, and data), and how many, that
would make use of either multiple independent transport connections (with their
own congestion control), or multiple streams within a QUIC or SCTP association?
 Would an unreliable datagram service be preferable to a retransmission-based /
reliable service for some or all of the streams?  Would FEC be useful?  The
rates discussed are very high; are there congestion control needs e.g. fast
startup, smooth/scalable responses, coupling with ABR, etc. that need to be
explored?