Subject: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Apr 2022 10:55:07 -0700

Hi all,

Comments on this draft before we move it forward.  I bounced around the
document as I went through this, checking references and whatnot, so this
is not in any particular order.

Generally, this seems to be in good shape.  Structurally, the major thing
that needs attention is the IANA stuff.  A pet peeve of mine in documents
these days is abuse of SHOULD, but this seems to have used it properly for
the most part (I raised a couple of them below) so kudos there.

This is an area of ART in which I'm not particularly strong, so it's
possible there are technical issues I've missed.  I'm trusting that the WG
and other reviewers are comfortable with how solid this is in that regard.

As a reminder, I will be around for the rest of this week and then on
vacation from IETF work until May.

-MSK

INTERESTING STUFF

SECTION 1

The first sentence of the first paragraph appears to be incomplete.

SECTION 7.1

This media type registration form is not complete.  Several sections are
missing.  Please use the template found in Section 5.6 of RFC 6838.  Also,
"Required Parameters" should be "N/A", not "None".

I suggest you include the completed template in Section 11.  It can refer
to Section 7.1 for all the details about the optional parameters, etc.

The general format of this section is also confusing.  For instance, it
gradually goes through all of the optional parameters, but then just after
"interop-constraints", which is an optional parameter, it gets into
"sprop-sublayer-id" which is not in the list at the top of the template.  I
can't tell if there should be a section break here, or if the list of
optional parameters is incomplete, or something else.

SECTION 3.2

This section lists "RPS" as an acronym used in this document, but it isn't.

SECTION 4.3.2

When would an implementation legitimately not do what the SHOULD says here?

SECTION 7.2.2.3

I don't understand the SHOULD here.  Can this work if an implementation
doesn't understand all of the media type parameters?  When might one
legitimately continue without that being the case?

APPENDIX A

Please add a note to the RFC Editor to delete this section prior to
publication (which I assume is the intent).

NITS

SECTION 1.1.1

"... the maximum size of coding tree unit ..." -- missing "a" or "the"?

s/signalling/signaling/

SECTION 1.1.2

s/labelled/labeled/

s/labelling/labeling/ (2x)

s/signalling/signaling/ (2x)

s/MPGEG/MPEG/

SECTION 1.1.3

s/signalling/signaling/ (3x)

SECTION 5

"... aggregation packet together one or more NAL units ..." -- missing a
"with"?

SECTION 6

"... RTP sequences number ..." -- s/sequences/sequence/

SECTION 7.1

s/signalling/signaling/

s/signalled/signaled/ (3x)

SECTION 10

s/achieving/achieved/

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 11 Apr 2022 18:37:34 +0000

Hi Murray,
Thanks for the review.  One question to you, and to the chairs, before we start editing: should we wait for sec-dir and transport-dir reviews?  Are there any of those requested?  Should there be?  (For previous video payload formats, sec-dir wanted to weigh in on the security section and transport on the congestion control.)
Stephan

From: avt <[email-masked]> on behalf of "Murray S. Kucherawy" <[email-masked]>
Date: Monday, April 11, 2022 at 10:55
To: IETF AVTCore WG <[email-masked]>
Subject: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

Hi all,

Comments on this draft before we move it forward.  I bounced around the document as I went through this, checking references and whatnot, so this is not in any particular order.

Generally, this seems to be in good shape.  Structurally, the major thing that needs attention is the IANA stuff.  A pet peeve of mine in documents these days is abuse of SHOULD, but this seems to have used it properly for the most part (I raised a couple of them below) so kudos there.

This is an area of ART in which I'm not particularly strong, so it's possible there are technical issues I've missed.  I'm trusting that the WG and other reviewers are comfortable with how solid this is in that regard.

As a reminder, I will be around for the rest of this week and then on vacation from IETF work until May.

-MSK

INTERESTING STUFF
SECTION 1

SECTION 7.1

This media type registration form is not complete.  Several sections are missing.  Please use the template found in Section 5.6 of RFC 6838.  Also, "Required Parameters" should be "N/A", not "None".

I suggest you include the completed template in Section 11.  It can refer to Section 7.1 for all the details about the optional parameters, etc.

The general format of this section is also confusing.  For instance, it gradually goes through all of the optional parameters, but then just after "interop-constraints", which is an optional parameter, it gets into "sprop-sublayer-id" which is not in the list at the top of the template.  I can't tell if there should be a section break here, or if the list of optional parameters is incomplete, or something else.

SECTION 3.2

SECTION 4.3.2

SECTION 7.2.2.3
I don't understand the SHOULD here.  Can this work if an implementation doesn't understand all of the media type parameters?  When might one legitimately continue without that being the case?

APPENDIX A

Please add a note to the RFC Editor to delete this section prior to publication (which I assume is the intent).

NITS
SECTION 1.1.1

s/signalling/signaling/

SECTION 1.1.2

s/labelled/labeled/

s/MPGEG/MPEG/

SECTION 1.1.3

SECTION 5

"... aggregation packet together one or more NAL units ..." -- missing a "with"?

SECTION 6

SECTION 7.1

s/signalling/signaling/

SECTION 10

s/achieving/achieved/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Apr 2022 18:24:04 -0700

I didn't request them because only WGLC has been done.  SECDIR will be
automatically requested once this enters IETF LC; we can add a TSVDIR
review too.

If the chairs want to request early reviews before we start IETF LC, that's
totally fine with me.

-MSK

On Mon, Apr 11, 2022 at 11:37 AM Stephan Wenger <[email-masked]> wrote:

> Hi Murray,
>
> Thanks for the review.  One question to you, and to the chairs, before we
> start editing: should we wait for sec-dir and transport-dir reviews?  Are
> there any of those requested?  Should there be?  (For previous video
> payload formats, sec-dir wanted to weigh in on the security section and
> transport on the congestion control.)
>
> Stephan
>
>
>
> *From: *avt <[email-masked]> on behalf of "Murray S. Kucherawy" <
> [email-masked]>
> *Date: *Monday, April 11, 2022 at 10:55
> *To: *IETF AVTCore WG <[email-masked]>
> *Subject: *[AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14
>
>
>
> Hi all,
>
>
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 12 Apr 2022 01:25:54 +0000

As those reviews are not yet underway, let’s rev the draft first.  Though it may take a while (early May, worst case), as an MPEG meeting is coming up and most of the draft authors will be busy.
S.

From: "Murray S. Kucherawy" <[email-masked]>
Date: Monday, April 11, 2022 at 18:24
To: Stephan Wenger <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, Jonathan Lennox <[email-masked]>, IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

I didn't request them because only WGLC has been done.  SECDIR will be automatically requested once this enters IETF LC; we can add a TSVDIR review too.

If the chairs want to request early reviews before we start IETF LC, that's totally fine with me.

-MSK

On Mon, Apr 11, 2022 at 11:37 AM Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:
Hi Murray,
Thanks for the review.  One question to you, and to the chairs, before we start editing: should we wait for sec-dir and transport-dir reviews?  Are there any of those requested?  Should there be?  (For previous video payload formats, sec-dir wanted to weigh in on the security section and transport on the congestion control.)
Stephan

From: avt <[email-masked]<mailto:[email-masked]>> on behalf of "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 11, 2022 at 10:55
To: IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>
Subject: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

Hi all,

-MSK

INTERESTING STUFF
SECTION 1

SECTION 7.1

SECTION 3.2

SECTION 4.3.2

SECTION 7.2.2.3

APPENDIX A

NITS
SECTION 1.1.1

s/signalling/signaling/

SECTION 1.1.2

s/labelled/labeled/

s/MPGEG/MPEG/

SECTION 1.1.3

SECTION 5

SECTION 6

SECTION 7.1

s/signalling/signaling/

SECTION 10

s/achieving/achieved/

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 14 Apr 2022 18:32:50 +0000

Hi Murray,
On the SHOULD-related points in your review, please see inline in blue.  Please advise whether you think additional text is warranted in the draft.  The “SHOULDs” themselves should IMO stay and not be replaced with different levels of mandation.
Stephan

[…]

SECTION 4.3.2

The context here is that the size of an aggregation packet SHOULD be chosen smaller than the MTU size.

We had similar language in RFC7798, and the reasons for it, AFAIR, were
-the path MTU size may not be known, hence it’s impossible to base a mandatory to implement packetization strategy on it; and
-there are legitimate reasons to create packets larger than the path MTU size, aggregation or others (see below).

For example, if the most lossy link of a path is known to support relatively large MTUs, it may make sense create packets (including AP) larger than the path MTU size but smaller than the MTU size of the critical link.  One example would be a small MTU over a reasonably reliable (because of its baked-in error control) wireless link, followed by the usual 1500 byte (or thereabouts) MTU over a congested segment of the Internet.  Losses are more likely to occur on the latter, hence, in this example, optimizing for the former is not advisable.
You may have noted that anything MTU related in this draft is at SHOULD level of mandation, for reasons like the above.

SECTION 7.2.2.3

This is one of many features that we copied over from RFC7798 without thinking much of it.  I vaguely recall that we had discussions and identified legitimate reasons at the RFC7798 time, roughly as follows: all of the media type parameters are OPTIONAL, for good and valid reasons—you don’t want to have a giant SDP blob when a few bytes of SDP will do.  It is a legitimate implementation strategy to not implement a parser that covers all these codepoints, because a receiver of an offer can reject that offer for whatever reason it chooses and doesn’t—in fact can’t—“justify” itself vis-à-vis the offeror.  The sentence with the SHOULD warns about the historically widely chosen implementation strategy of implementing none or only a subset of the optional parameters, but doesn’t close the door on it, simply because we don’t want to render all implementations that take above shortcut as non-compliant, with all that entails.  (In that regard, remember that a) we’re not the protocol police, but b) there are IPR declarations against this draft, as are against RFC7798, some of which recite standards compliance.  We video coding people are very IPR-conscious :-)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Apr 2022 15:53:15 -0700

Stephan said:

"-the path MTU size may not be known, hence it’s impossible to base a
mandatory to implement packetization strategy on it;"

[BA] This is particularly true in a conferencing scenario where the sender
does not communicate directly with the other conference participants and
has no idea what the MTU is on each of the sender -> MANE -> receiver
paths.  Also, the MANE may not desire to, or be capable of, re-packetizing
(e.g. where E2E encryption is used).

"I don't understand the SHOULD here.  Can this work if an implementation
doesn't understand all of the media type parameters?  When might one
legitimately continue without that being the case?"

[BA] Looking at this again, it seems somewhat unclear. An Answerer needs to
understand the Offer well enough to be able to determine how to respond to
it, and there are some parameters that must be implemented, not just
understood. For example, it's hard to see the negotiation working without
both the Offerer and Answerer at least implementing the basics (e.g.
profile-id, level-id, etc.).

The last sentence of the paragraph is hard to understand.  There are too
many dissonant uses of the term "receiver". Does "an offer to receive
media" mean an Offer with a recv-only m-line? By "receiver is capable" do
you mean "Answerer is capable"?
Does "receiver of the offer" mean "Answerer"?  I think you are trying to
say that an Answerer has to understand the Offer's receiver capabilities
well enough to not exceed them.  Is that right?

   A receiver SHOULD understand all media type parameters, even if it
   only supports a subset of the payload format's functionality.  This
   ensures that a receiver is capable of understanding when an offer to
   receive media can be downgraded to what is supported by the receiver
   of the offer.

On Thu, Apr 14, 2022 at 11:33 AM Stephan Wenger <[email-masked]> wrote:

> Hi Murray,
>
> On the SHOULD-related points in your review, please see inline in blue.
> Please advise whether you think additional text is warranted in the draft.
> The “SHOULDs” themselves should IMO stay and not be replaced with different
> levels of mandation.
>
> Stephan
>
>
>
>
>
> -the path MTU size may not be known, hence it’s impossible to base a
> mandatory to implement packetization strategy on it; and
>
> For example, if the most lossy link of a path is known to support
> relatively large MTUs, it may make sense create packets (including AP)
> larger than the path MTU size but smaller than the MTU size of the critical
> link.  One example would be a small MTU over a reasonably reliable (because
> of its baked-in error control) wireless link, followed by the usual 1500
> byte (or thereabouts) MTU over a congested segment of the Internet.  Losses
> are more likely to occur on the latter, hence, in this example, optimizing
> for the former is not advisable.
>
> You may have noted that anything MTU related in this draft is at SHOULD
> level of mandation, for reasons like the above.
>
>
>
>
>
>
>
> SECTION 7.2.2.3
>
> This is one of many features that we copied over from RFC7798 without
> thinking much of it.  I vaguely recall that we had discussions and
> identified legitimate reasons at the RFC7798 time, roughly as follows: all
> of the media type parameters are OPTIONAL, for good and valid reasons—you
> don’t want to have a giant SDP blob when a few bytes of SDP will do.  It is
> a legitimate implementation strategy to not implement a parser that covers
> all these codepoints, because a receiver of an offer can reject that offer
> for whatever reason it chooses and doesn’t—in fact can’t—“justify” itself
> vis-à-vis the offeror.  The sentence with the SHOULD warns about the
> historically widely chosen implementation strategy of implementing none or
> only a subset of the optional parameters, but doesn’t close the door on it,
> simply because we don’t want to render all implementations that take above
> shortcut as non-compliant, with all that entails.  (In that regard,
> remember that a) we’re not the protocol police, but b) there are IPR
> declarations against this draft, as are against RFC7798, some of which
> recite standards compliance.  We video coding people are very IPR-conscious
> :-)
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 14 Apr 2022 23:37:29 +0000

Hi Bernard,
pls see inline in this shade of blue.
S.

From: Bernard Aboba <[email-masked]>
Date: Thursday, April 14, 2022 at 15:53
To: Stephan Wenger <[email-masked]>
Cc: "Murray S. Kucherawy" <[email-masked]>, IETF AVTCore WG <[email-masked]>
Subject: Re: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14

Stephan said:

"-the path MTU size may not be known, hence it’s impossible to base a mandatory to implement packetization strategy on it;"

[BA] This is particularly true in a conferencing scenario where the sender does not communicate directly with the other conference participants and has no idea what the MTU is on each of the sender -> MANE -> receiver paths.  Also, the MANE may not desire to, or be capable of, re-packetizing (e.g. where E2E encryption is used).

"I don't understand the SHOULD here.  Can this work if an implementation doesn't understand all of the media type parameters?  When might one legitimately continue without that being the case?"

[BA] Looking at this again, it seems somewhat unclear. An Answerer needs to understand the Offer well enough to be able to determine how to respond to it, and there are some parameters that must be implemented, not just understood. For example, it's hard to see the negotiation working without both the Offerer and Answerer at least implementing the basics (e.g. profile-id, level-id, etc.).

The design philosophy we followed in RFC3984, RFC7798, and here as well (unless we made a mistake) is that every parameter is optional, but every parameter also has a (what we believe sensibly chosen) default value.  Insofar, yes, you can build a system that doesn’t parse the optional parameter at all.
The “sensibly chosen” default parameters are hard-coded in the spec as main profile, level 3.1 , basic tier.  As it’s main profile, the various scalability-related parameters are irrelevant.  All the buffering stuff is set to the max the VVC spec allows.  No inband parameter sets.  And, we simplified the spec compared to earlier payload formats in saying that all single NAL unit, Aggregation, and Fragmentation formats MUST be implemented, which I believe is consistent with more recent implementation practice anyway.

The last sentence of the paragraph is hard to understand.  There are too many dissonant uses of the term "receiver". Does "an offer to receive media" mean an Offer with a recv-only m-line? By "receiver is capable" do you mean "Answerer is capable"?
Does "receiver of the offer" mean "Answerer"?  I think you are trying to say that an Answerer has to understand the Offer's receiver capabilities well enough to not exceed them.  Is that right?

   of the offer.

Yes, I believe your edited paragraph is capturing what we wanted to express.  (I may remark that none of us authors are English native speakers, and at least the Finns and the Germans among us love long, complex sentences (and nouns) :-).  That’s perhaps the background of the complex sentence we have right now.

On Thu, Apr 14, 2022 at 11:33 AM Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:
Hi Murray,
On the SHOULD-related points in your review, please see inline in blue.  Please advise whether you think additional text is warranted in the draft.  The “SHOULDs” themselves should IMO stay and not be replaced with different levels of mandation.
Stephan

[…]

SECTION 4.3.2

SECTION 7.2.2.3

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt