Re: [Tsv-art] Tsvart last call review of draft-ietf-mops-streaming-opcons-10

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 25 May 2022 20:25 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07F3C07B7C1; Wed, 25 May 2022 13:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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_DNSWL_HI=-5, 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 gyqpMZ942Whs; Wed, 25 May 2022 13:25:15 -0700 (PDT)
Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 8DD82C07B7BD; Wed, 25 May 2022 13:25:15 -0700 (PDT)
Received: by mail-vs1-xe36.google.com with SMTP id j7so10506029vsp.12; Wed, 25 May 2022 13:25:15 -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=TnF6VSWE4BNDvRdolfFcCoplk+Mls9KYFmZKWwZUj54=; b=FwT7POAA7D+GqpyX5OO9QIvKuVxWo4Npm20iMxfleHouy1ec9iXDWI0oEB+Ugqgqsn 9RsA0CtX2livn4dl9f8y2Z4Hn3vZNENrjJBcFvIQYUPv4R+ZzxettTKdgQQGguuyLzSD ufKCI4xGpgXdO3ur7ISDQduxdY+Lmg7Reqe+QhGjqwllssRHokLZaE/8PtK/rn7Kv7rv 1RjXRyk+3z5bNRyGk04YDgvNA0XcGmQfWJFzYucRuPAzwT/3cDL+mMT/i/aPdbl/ciNa cwiCMMm4n1GxI1soVDP7sS1iGljH1LVGq8FQj9/YsRTCuw9TrlhlE11ngkWOHVceowXf 2S+Q==
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=TnF6VSWE4BNDvRdolfFcCoplk+Mls9KYFmZKWwZUj54=; b=fYsrFrcTXaUlkDx5dtKd0XGtf5dRolJpE4snzZPEJ3vnV0HR6fxDGjOa/YMNpSzV4e RQOAqa8ZT+Ddvwhd0f21GMB+MSSIF8JEzF1kJmEt7gO32Zph+KTWzvK2ZHcPr+NO32di FbVaV+TGQNYwNfxPsOVWLShbDejjOJam6GfeilW4i2fVi3ewctDvkNki71NSRl+RLlsC 09qvTaVIrzhs0DPjKi0QAnrbuH7vd3qwm51YfRFo406VfANf1IHWMGzjKyjrBbz/zgUv no9E6JjR9Hti6WlhyyWueLQ6v5Wrql2ihQhujB+NJC38clRmMN5lW3CuagbK2dQlzNqm +LVQ==
X-Gm-Message-State: AOAM530580hg7I7aX/cVHvFiyi5rrW/3limtzhFNt0sKuka1VvJRlmYW aCDTfdFSQaveco9/jV4BR3XdXItwz5CIPsqQlPaOhv5Cn4w=
X-Google-Smtp-Source: ABdhPJwy8lWQnX4hisOkyNWDIka9pNCzp4TuMOtxwpdha3cwwozMwbLHPlkpI6eY6jxUjdbRcrlLDxsIj3rhNuZV5ns=
X-Received: by 2002:a05:6102:e92:b0:335:bb5a:9d1 with SMTP id l18-20020a0561020e9200b00335bb5a09d1mr14258051vst.43.1653510314308; Wed, 25 May 2022 13:25:14 -0700 (PDT)
MIME-Version: 1.0
References: <165125761097.7054.12391892807605430077@ietfa.amsl.com>
In-Reply-To: <165125761097.7054.12391892807605430077@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 25 May 2022 15:24:48 -0500
Message-ID: <CAKKJt-cohxOm7z0PByC=+h2O+h6Y6RkBSYfo-bxDpkLvhj3ZpA@mail.gmail.com>
To: Michael Scharf <michael.scharf@hs-esslingen.de>
Cc: tsv-art@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="000000000000eab97805dfdbde13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/tf5CSJufAhMqtsXpRfIWYj1YUNQ>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-mops-streaming-opcons-10
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 20:25:16 -0000

Hi, Michael,

My apologies for my delay in responding.

I'm now digging through the Last Call and telechat ballor comments we've
received, and want to catch you up on how things look.

Most of the issues we created from this review are assigned to me in
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues.

Just to record them on the mailing list for other folks ...

On Fri, Apr 29, 2022 at 1:40 PM Michael Scharf via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Michael Scharf
> Review result: Ready with Issues
>
> 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.
>

^^^ these were helpful observations, and will inform our responses to more
specific comments (listed below).


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/137


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/138


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/139


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/140


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/130

(muttering to myself) "everyone else is surprised about ultra low latency,
too")


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/141

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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/142


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134
- your comment was added to the intdir issue.


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/144


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


https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/143


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/145


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

 https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/146

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

Noted in
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/141


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

https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/147