[AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 07 November 2023 16:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A636C15199D for <avt@ietfa.amsl.com>; Tue, 7 Nov 2023 08:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 y4tHeClCFu1z for <avt@ietfa.amsl.com>; Tue, 7 Nov 2023 08:59:50 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 72E28C17060B for <avt@ietf.org>; Tue, 7 Nov 2023 08:59:45 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-565334377d0so4377122a12.2 for <avt@ietf.org>; Tue, 07 Nov 2023 08:59:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699376385; x=1699981185; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/hYalNF74S5Y+tEPyD59nRM8oFgO47RZxGsYKcJRc3g=; b=mdqFm7lXgroD4/wY1+8qowtxm8mjCvHiuT38Pa4HDDhM9gBUHjQfSbMuN+12/njzrn P9+3XusczxAY0i5qljLGZjdITbZ+jqOKeqv/aJo85WwWI+mfX8upilYqlSd4aq90aWbu EAcT+rr42DpS5WcjaeqEwOI5/7qgzFG5VAhAiuVT5VZvCQhDh4EM0vAj0ZtbRhsRCFSG u4TWKJ2agJ8437NZVKzKNysv86zDFStHhwk/p2HDkJmZHsjA8NLe3q/YUHsfrzCLtunC 9ktfTwzYmm5xRNwIMCYyPEwwWmF3mP1+zgauRJbVK0nU5m+AEkpG9xNFSHKPQZY+wldf z9Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699376385; x=1699981185; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/hYalNF74S5Y+tEPyD59nRM8oFgO47RZxGsYKcJRc3g=; b=uAgaSTWy7N5OvOLO5Qx+BGiE+zm5729bBL8s1OPSrhlyFr6Jf3MrJsEEWgvUoPrpjd P0qzSfGOcf0B9tjCs+EKmj7p6cyOo/crg4HRPRGlNRMp/BZEH71gnXN7QE/7G660ceS9 rMEgggn80LVKv0H1q6FsvFQHLmmMpJzunYyIYTttp3rp7RW8BbuJ3hXGconyv3icuDvD o00z2AFK8NhgFmPerCZXkrWIZ1FNyql/4uS8YKgAD1+VUTj4L256fpzGL//OvdmPmmjR X9N8FXn/0yS/TAlm98P27WjlcwOvHrjb9YoNGIwPyw9zbfDzbVjJ+AximmAboEkz1+yG Gcmg==
X-Gm-Message-State: AOJu0YybG4Wko+lmo2OD+N6TOtnEL2vARGFUP+6AWsMNj+NE5InWvkaf 4gOqNjAkebgu/+CvgvMKW3EeA/e7m51OZfOxGeVbjPaAnok=
X-Google-Smtp-Source: AGHT+IEZ+M5F64wMg2G0ywS0p4idsdm9CfbRGUFHtyL55MePSImriO61ipFl1LnJz9w5nxb9OVB1azoZkzIfMcqlO60=
X-Received: by 2002:a05:6a20:3942:b0:16b:79b3:222b with SMTP id r2-20020a056a20394200b0016b79b3222bmr41172846pzg.34.1699376384531; Tue, 07 Nov 2023 08:59:44 -0800 (PST)
MIME-Version: 1.0
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 07 Nov 2023 10:59:17 -0600
Message-ID: <CAKKJt-exSpN4g27V-9HzEBpi6iheLFgNiOFNwGtuKygx_Gub+Q@mail.gmail.com>
To: Hyunsik Yang <Hyunsik.Yang@interdigital.com>, Xavier De Foy <Xavier.DeFoy@interdigital.com>
Cc: IETF AVTCore WG <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd650e060992e5e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/I9lRkPtHPqWaU1JVEdGxAjwPCaw>
Subject: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 16:59:54 -0000

Hi, Hyunsik and Xavier,

Thank you for submitting this draft to AVTCORE. I do have some suggestions,
but overall, I think it's quite good. and very close to being
adoption-ready.


Most of my suggestions are opportunities for clarifications.

Please feel free to ask for clarifications, or reply, on the AVTCORE
mailing list.


Best,


Spencer


   -

   One major point, but fortunately, it's only a process point you're
   addressing early - this spec uses [ISO.IEC.23090-31], which is not freely
   downloadable by just anyone. The good news is that Stephan Wegner, the IETF
   liaison manager for JTC1/SC 29, has experience with obtaining copies of
   JTC1/SC 29 specifications for reviewers - he told me you should send him
   the FCD, and he will distribute it to only those IETF people who have need
   to know.



   -

   Nit: please expand acronyms on first use, especially in the Abstract,
   and especially "MIHS!"



   -

   Nit: please update the Conventions section to reflect BCP14, and include
   RFC2119 and RFC8174 as a Normative References, as


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
shown here.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <
https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP
14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <
https://www.rfc-editor.org/rfc/rfc8174>.


   -

   In Section 3, terminology, this might be clearer:


This document uses the definitions of the MPEG Haptics Coding standard
[ISO.IEC.23090-31]. Some terms from that document are provided here for
convenience.


   -

   For Section 4.1, please add "hmpg" to the Definitions section, with its
   expansion



   -

   For Section 4.2, please add "independent", "sync", "dependent",
   "non-sync", "time-independent", and "time-dependent" to the Definitions
   section



   -

    For Section 4.3, I'm puzzled by the use of SHOULD, for a new
   specification that hasn't been deployed. Upon reflection, I don't think the
   considerations in this section need to be normative at all. Here's my
   suggestion:


The following considerations apply for the streaming of MIHS over RTP:

If a media sender sets durations with the same value for all non-zero
duration MIHS units between initialization MIHS units, this will make the
decoder more robust to RTP packet loss.

If a media sender sends one, or a few, MIHS silent units at the beginning
of a haptic silence, and does not send subsequent consecutive silent units,
this will allow the sender and receiver to save network resources.

If a media receiver receives a MIHS silent unit, the receiver can assume
that silence is intended until the reception of a non-silent MIHS unit.
This will make the decoder more robust to RTP packet loss.

EDITOR'S NOTE: these considerations may need to be re-evaluated depending
on the finalization of the haptics coding specifications in MPEG.


   -

   For Section 5.2, each of the field descriptions includes both the
   description of the field, and language about the way different values are
   processed by the receiver. I suggest moving the language about processing
   to section 5.3. So, for example,


D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit
included in the RTP payload is, when its value is one, dependent (i.e.,
"non-sync") or, when its value is zero, independent (i.e., "sync"). In case
of congestion, a receiver or intermediate node MAY prioritize independent
packets over dependent ones, since the non reception of an independent MIHS
unit can prevent the decoding of multiple subsequent dependent MIHS units.

would be split into

D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit
included in the RTP payload is, when its value is one, dependent (i.e.,
"non-sync") or, when its value is zero, independent (i.e., "sync").

in Section 5.2, and

In case of congestion, a receiver or intermediate node MAY prioritize
independent packets over dependent ones, since the non reception of an
independent MIHS unit can prevent the decoding of multiple subsequent
dependent MIHS units.


   -

   In Section 5.3, there's a mention of "aggregation". This would be
   clearer if the text said


Editor's Note: consider if it would be useful to add the ability to
aggregate multiple MIHS units in a single RTP payload - for instance, to
aggregate multiple MIHS units with different layer values into a single RTP
payload.


   -

   In Section 5.3, there's a figure that contains the payload structure
   type values. It would be good to also provide a figure that contains the
   MIHS Layer values, with a pointer from the description in Section 5.2.



   -

   In Section 5.3.2, it would be good to point out that the use of MIHS
   Unit Fragmentation in RTP means that a media receiver can receive some
   fragments, but not other fragments, and the missing fragments would not be
   retransmitted by RTP. If there is any danger of an actuator behaving oddly
   because it interpreted a partial MIHS Unit Fragment, you might want to
   mention that, as guidance to implementers.



   -

   In Section 6, is it correct to say


"This section specifies the optional parameters.described in
[ISO.IEC.23090-31]"?


   -

   In Section 6.1, I suggest moving this text to the end of Section 6:


The receiver MUST ignore any parameter unspecified in this memo.


   -

   In Section 6.1, this looks a lot like an IANA Considerations section,
   but the information here is much abbreviated, compared to
   https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations.
   Since Section 10, IANA Considerations, just says "see Section 6", I'd
   suggest adding all of the attributes used in those registrations,
   especially since
   https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations
   says those registrations are also provided as examples. Alternatively, you
   could move the rest of Section 6 (including 6.1 and 6.2) into the IANA
   Considerations section, where IANA would be looking for what you want them
   to know, anyway.



   -

   In Section 6.2 - I know this is going to be complicated, but I'll do my
   best. 🙃


My understanding - please correct me - is that most or all of these
optional parameters are described in [ISO.IEC.23090-31], including values,
and all that we're doing here is naming the parameters in a way that SDP
would understand. So I THINK all that's required in this document, is to
say (for example)

Corresponding parameter in [ISO.IEC.23090-31]

SDP Parameter Name

…

…

avatar type

hmpg-avtypes

…

…

If the IETF will not define new SDP parameters without a change to
[ISO.IEC.23090-31], that should be about right. The other option would be
to include values for each SDP parameter name from [ISO.IEC.23090-31], for
the convenience of the reader.

If the IETF wants to use existing parameters that are already defined in
[ISO.IEC.23090-31], we can update this RFC, or we could create an IANA
registry for these parameters, with

Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic
Coding)

HOWEVER, if the IETF wants to use NEW parameters that are defined in
revisions to [ISO.IEC.23090-31], using an IANA registry for these
parameters becomes much more appealing.

If the IETF ever decides to define new parameters that aren't already in a
JTC1/SC 29/WG 7 specification, using an IANA registry is almost certainly
the Right Thing To Do.

I note that our AD, Murray Kucherawy, is a backup Designated Expert for
https://www.iana.org/assignments/media-types/media-types.xhtml, and you're
already talking to Stephan Wegner, the IETF liaison manager for JTC1/SC 29
about availability of [ISO.IEC.23090-31] for reviewers, I'm sure AVTCORE
has the wisdom I lack, to work through all the details here!