Re: [Mops] Intdir last call review of draft-ietf-mops-streaming-opcons-10

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 18 May 2022 17:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D7C15E3E3; Wed, 18 May 2022 10:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eU4Diu-mKOk; Wed, 18 May 2022 10:59:04 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3586C15E3E6; Wed, 18 May 2022 10:58:58 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id z6so2755878vsp.0; Wed, 18 May 2022 10:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SiV39Hb1fq9mctKE3IpxlJ59fiVCK4pQLJO9lSrVbFg=; b=NlLp9kjurQhBJSrDkhc2SBBcqwuRpqC5AKSIL8hN3KuHNaaH8SR9i3wgQpC0djHjrn vboQCKd0xwNuct9L7D1GymBqGMuSLbU6+tzQoYROKp9YBt/iJ3GhnIZIWf+ssyOWBnNz frI/+TRI6bJFcrnZCIiIMto7cyrawT++Nj2wc7xZ/BNeDWOoxigqfpMX6/imAgVx2Wgp iQOTFOLKdF83JOBTVH0jq7N3zalcKY5wSeVtHPDH9uu9nXT9h+6GKqMSXSko7YFIglUn 6aTe//zq+nQgf/0OmJmoPt1Y7dwXMQN5+IaDtXkrfIwJXkqx3i88HIbso4nvsfLYqpCH YJrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SiV39Hb1fq9mctKE3IpxlJ59fiVCK4pQLJO9lSrVbFg=; b=IAcGzqXS1M50CB0scoK5kikr79BTENnRev/fqZkH6jSYoBQm71HDIMslmQa9bI1m3w voNhTg+N2H/h06LbkowFiQoE4p67I0V+izcswzVh0Aj2ygUlFXk9RrlD7soL35Rs7GKW LxlhWcyrLvpJogKR9z3h9XyEj+S4KVw6aepK3EetTngg9mXLKHcwvR4KK2BuELQJbV3S 0i/xLpgKi5uZTw4uEbXnXigDo6xSY1KqAGVszBedkILo7PHMzPijzoTsj26a4DXhjEXy J4Bfk+XSg6ITyhR7UYJCnlHJPKfzIIDxFv4MitcmwJkd3MjU8/jGU7yZbaMNKDmOMpxQ YSoA==
X-Gm-Message-State: AOAM533ttLWBIWNoqWLGejh+Z8GNcPZJ+Kr5OWbd4BuWN9fV6bEjvZpV z9HKasb0J+u3yDXDCyRi0u30QW+28LrDWa1H7nA=
X-Google-Smtp-Source: ABdhPJwC8VUsfOmdMyEPp45T0mEhxUVal0o24NCRbKO/qEoBgfiFa4SSWpOmgoaZiy4g+19+Qwpi8Ry+rIVAta66Gik=
X-Received: by 2002:a05:6102:32d3:b0:32d:6f0e:646f with SMTP id o19-20020a05610232d300b0032d6f0e646fmr558253vss.29.1652896737545; Wed, 18 May 2022 10:58:57 -0700 (PDT)
MIME-Version: 1.0
References: <165101722865.2081.3670693790800204057@ietfa.amsl.com>
In-Reply-To: <165101722865.2081.3670693790800204057@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 18 May 2022 12:58:31 -0500
Message-ID: <CAKKJt-e5xDZP7a1+N2hzyjjDykPQCJPOWZAuHv7FpAWkx7xTZw@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: int-dir@ietf.org, draft-ietf-mops-streaming-opcons.all@ietf.org, last-call@ietf.org, MOPS Working Group <mops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e4554b05df4d0220"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/halyVbOBX9_nygalUbCOMubL2gU>
Subject: Re: [Mops] Intdir last call review of draft-ietf-mops-streaming-opcons-10
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2022 17:59:05 -0000

Hi, Tommy,

My apologies for my slow email response.

We've entered GitHub issues for each of these comments, as below ...

On Tue, Apr 26, 2022 at 6:53 PM Tommy Pauly via Datatracker <
noreply@ietf.org> wrote:

> 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).
>

This is
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/131

I agreed. I think this is fixed in
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/pull/135


> - 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.
>

This is
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/132.


> - 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.
>

This is
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/133

I agree with you on this one. The text may not survive comment resolution
on Michael Scharf's TSVART review, but I'll fix this, if it does.

- 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.
>

This is
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134.

I agree. I think the resolution here may subsumed in resolving comments
from Michael's TSVART review (for example,
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134),
but if it's not, I'll fix it.

Best,

Spencer