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

[Stephan Wenger <[e-mail]>]

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]> on behalf of "Murray S. Kucherawy" <[e-mail]>
Date: Monday, April 11, 2022 at 10:55
To: IETF AVTCore WG <[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 :-)