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

[Bernard Aboba <[e-mail]>]

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 <[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]> 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
> :-)
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>