[Int-dir] Intdir last call review of draft-ietf-mops-streaming-opcons-10

Tommy Pauly via Datatracker <noreply@ietf.org> Tue, 26 April 2022 23:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D70C1D0B1E; Tue, 26 Apr 2022 16:53:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tommy Pauly via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-mops-streaming-opcons.all@ietf.org, last-call@ietf.org, mops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165101722865.2081.3670693790800204057@ietfa.amsl.com>
Reply-To: Tommy Pauly <tpauly@apple.com>
Date: Tue, 26 Apr 2022 16:53:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/JpjP05OueGfNnu9xA1cT5wMVX84>
Subject: [Int-dir] Intdir last call review of draft-ietf-mops-streaming-opcons-10
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.34
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2022 23:53:48 -0000

Reviewer: Tommy Pauly
Review result: Ready with Nits

Thanks to the authors for a well-written document. It is structured clearly,
and explains the space nicely.

I have a few nit comments that could improve the document further (written as
an IntArea review, but with some general nits as well):

- Section 3.2.1 says, "There are many reasons why path characteristics might
change suddenly...". It may be good to mention MTU changes as part of the path
changes, since changes in the maximum packet sizes supported by paths can be
disruptive to traffic (requiring new PMTUD, etc).

- There are places that could benefit from more citations. For example, Section
3.5 says, "Historical data shows that users consume more videos and at a higher
bit rate than they did in the past..." but does not explain what data this is.

- In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is
often used to send a single-packet request to look up the IP address for a DNS
name, and return a single-packet response containing the IP address." I'm not
sure how valuable this example is for explaining UDP, but if it is kept, please
say that *multiple* packets are sent to get *multiple* addresses. With IPv6 and
IPv4, clients query for both A and AAAA records, and handle multiple addresses,
especially for IPv6.

- As a bit of transport commentary, I don't find the setup of Section 6
compelling. While UDP is a transport in a technical sense, for the purpose of
media, it is almost always a layer upon which the protocol doing the congestion
control work runs. To that end, QUIC is just another more standardized case of
this, just like SCTP over UDP. Rather than talking about "UDP's behavior" vs
"TCP's behavior", I suggest talking about how applications over UDP for media
behave vs applications over TCP for media behave.