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

[Stephan Wenger <[e-mail]>]

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

From: Bernard Aboba <[e-mail]>
Date: Thursday, April 14, 2022 at 15:53
To: Stephan Wenger <[e-mail]>
Cc: "Murray S. Kucherawy" <[e-mail]>om>, IETF AVTCore WG <[e-mail]>
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?


   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.

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 <[e-mail]<mailto:[e-mail]>> 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


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

[…]

SECTION 4.3.2

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

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

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/avt