Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)

[Bernard Aboba <[e-mail]>]

From my perspective the adjusted RFC language looks good and the additional clarification isn’t needed.

> On Jul 30, 2022, at 07:10, Stephan Wenger <[e-mail]> wrote:
> 
> 
> Hi Zahed, Magnus, all,
>  
> Adding Magnus to the CC list, as he’s the inventor of the sprop concept.
>  
> I looked into this a bit more.
>  
> Using the guidance of RFC3984, the right place for additional warning language regarding sprop would be in section 7 right after the first (and currently sole) paragraph.  I don’t believe we want the informative language further down in section 7.1 and as part of the media type registration.  As Martin Duerst has pointed out, that section is already on the long side.
>  
> The only signaling concept that I’m aware of where sprop is “special” seems to be offer/answer.  Insofar, another place could also be section 7.3.2.  However, that section is already quite specific about many of the sprop parameters, hence placing additional informative language there seems redundant.
>  
> As for the 3984 language, it needs to be fine-tuned to reflect the media type registration for VVC.  Also, by today’s standards, the language is quite handwaving and vague, and I think a bit of tightening is in order.  For example, rather than “SHOULD avoid” language for “some signaling protocol concepts” of RFC3984, I think we are better off to call out offer/answer specifically.  Finally, the RFC3984 language clearly shows grammar influenced by German/Swedish authors, and that should be tightened as well.
>  
> I think the text from RFC3984 should be modified to the following:
> OLD (from RFC3984):
>    Some parameters provide a receiver with the properties of the stream
>    that will be sent.  The name of all these parameters starts with
>    "sprop" for stream properties.  Some of these "sprop" parameters are
>    limited by other payload or codec configuration parameters.  For
>    example, the sprop-parameter-sets parameter is constrained by the
>    profile-level-id parameter.  The media sender selects all "sprop"
>    parameters rather than the receiver.  This uncommon characteristic of
>    the "sprop" parameters may not be compatible with some signaling
>    protocol concepts, in which case the use of these parameters SHOULD
>    be avoided.
>  
>  
> NEW (to VVC payload draft):
>    Parameters starting with the string “sprop” for stream properties can
>    be used by a sender to provide a receiver with the properties of the
>    stream that is or will be sent. 
>    The media sender (and not the receiver) selects whether, and with what values,
>    "sprop" parameters are being sent. This uncommon characteristic of the "sprop"
>    parameters may not be intuitive in the context of some signaling protocol
>    concepts, especially with offer/answer.  Please see also section 7.3.2 for
>    guidance specific to the use of sprop parameters in the Offer/Answer case.
>  
> I don’t think that the RFC3984 language regarding possible dependencies of sprop parameters to other parameters or the stream itself is particularly useful; hence it is omitted in the above.  If you guys disagree, we could include something like the below:
>  
>    Some of the "sprop" parameters are
>    limited by other payload or codec configuration parameters.  For example,
>    the sprop-ols-id parameter is relevant only for streams that use scalable
>    profiles, and therefore its use makes only sense if the profile-id parameter
>    indicates one of the scalable profiles.  Further, the value of sprop-ols-id
>    is useless if it would refer to an invalid entry in the output layer set
>    as defined by the bitstream itself.
>  
>  
> Reactions?
>  
> Thanks,
> Stephan
>  
>  
>  
> From: Zaheduzzaman Sarker <[e-mail]>
> Date: Friday, July 29, 2022 at 13:43
> To: Stephan Wenger <[e-mail]>, The IESG <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: RE: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)
>  
> Hi Stefan,
>  
> Thanks for addressing my comments.
>  
> See below inline tagged with [ZS].
>  
> //Zahed
>  
> From: Stephan Wenger <[e-mail]> 
> Sent: den 16 juni 2022 10:35
> To: Zaheduzzaman Sarker <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)
>  
> Hi Zahed 
> Thanks for your review.  Please see inline in blue.
> Stephan
>  
> On 6/16/22, 06:00, "Zaheduzzaman Sarker via Datatracker" <[e-mail]> wrote:
>  
> […]
>  
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
>  
>  
>  
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>  
>     I would like discuss if this specification should be making stronger statement
>     to enforce the reinterpretation the SDP Offer/Answer model for parameters
>     sprop-max-don-diff and sprop-depack-buf-bytes.
>  
>     In section 7.3.2.3, it says sprop-max-don-diff and sprop-depack-buf-bytes
>     parameter should be interpreted differently than usual interpretation of the
>     parameters according to RFC 3264. This is a significant change and kind of easy
>     to miss. This section does not use any normative text to enforce the change
>     either.
>  
> None of us authors is an SDP expert or has much interest in SDP (anymore).  Outside of the webrtc context, few use SDP for video nowadays.  The world has moved on to Jitsi and proprietary solutions and whatnot.  The webrtc guys still use SDP but seem to have subscribed to non-ITU video codecs and Opus, at least for last several years, and I do not see that their interest in ITU codecs comes back anytime soon.  I’m writing this not to justify shortcomings, but rather to explain that the energy that went into the signaling part of this draft was quite low.  We simply copied from RFC 7798 (RTP payload format for H.265) what we thought we needed, and adjusted what needed to be adjusted.  The latter was mostly names and references, and adjustments related to the few differences between H.265 and H.266. 
>  
> If it were up to us authors, we would likely have omitted the signaling part of this payload format and/or moved it to a different document, to be processed if and when the need for it is shown, and by people who know what they are doing.  However, that would have gone against a standing agreement in the AVT working group.  (I personally have objected to that standing agreement in the past, noisily so, but do not plan to bang my head against this particular wall again.)
>  
> To the subject of the DISCUSS: The concept of sender-properties (sprop) and its diverging interpretation from traditional O/A exchanges was introduced by Magnus Westerlund, goes back to RFC3984 and, at the time, has led to long and hard discussions in AVT.  That was almost 20 years back and at a time when SDP still had relevance.  I think that the sprop concept was battle-proofed then; it was used in products, 3GPP specs referenced it, and so forth. Both sprop-max-don-diff and an equivalent to sprop-depack-buf-bytes (known as sprop-deint-buf-req)  were part of RFC 3984.  Like in the subject draft, also RFC3984 contains no normative language related to their use, and the relevant language explaining their purpose is virtually identical to what we have now.  See the second bullet of section 8.2.2 of RFC3984 if you are interested.  (https://datatracker.ietf.org/doc/html/rfc3984 #section-8.2.2).  I do not recall having ever received inquiries about sprop, and I also do not recall that sprop-related issues ever came up in interop events (which were, at the time conducted in places like the IMTC).
> Since then, sprop-style parameters, in essentially unmodified form have been copy-pasted into every RTP payload format for NAL-unit-based video codecs.  Given that SDP is essentiality legacy technology nowadays, I would think that the handful of people that may be reading this part of the payload format spec are likely familiar with it.  The rest (like us) doesn’t care, as (like us) they will focus almost exclusively on the media plane. 
>  
> Therefore, I suggest no change.
>  
> If that were unacceptable to you, then please help us with identifying a solution that satisfies your request.  I assume this would be a sentence or two early in section 7.3.2.3. 
>  
> [ZS] As we talked during the IETF meeting and as per your note in the AVTCORE session, I think the current plan of updating the draft with non-normative text is the right thing to do here. I am expecting calling out the sprop as sender behavior in the draft hence making a ground for modified SDP offer/answer model. See the text from RFC3984 –
>  
> Some parameters provide a receiver with the properties of the stream
>    that will be sent.  The name of all these parameters starts with
>    "sprop" for stream properties.  Some of these "sprop" parameters are
>    limited by other payload or codec configuration parameters.  For
>    example, the sprop-parameter-sets parameter is constrained by the
>    profile-level-id parameter.  The media sender selects all "sprop"
>    parameters rather than the receiver.  This uncommon characteristic of
>    the "sprop" parameters may not be compatible with some signaling
>    protocol concepts, in which case the use of these parameters SHOULD
>    be avoided.
>  
> Some modified version of this text will do good here.
>  
>  
> [ZS] Your resolutions for the rest of the observations I have looks good to me.
>  
>  
>  
>  
>     I am also supporting Francesca's discuss.
>  
> Please see my reply to Francesca’s review from yesterday.
>  
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>  
>     Thanks for working on this specification. This is a big task to define payload
>     format for a video codec.
>  
>     I would note that the VVC specifications are behind paywall and we are heavily
>     depended on the interpretation of the authors of the actual specification here.
>     I hope the specification was somehow made available to the working group to
>     have a look while developing this specification. Having said that I must thank
>     the authors for providing details of the video codec specification that made
>     this review possible.
>  
> One other AD also complained about the VVC spec not being publicly available for free.  That is not true.  Like all ITU Recs, also this one is available for free download.  H.266 is available from here: https://www.itu.int/itu-t/recommendations/rec.aspx?rec=14948  What’s currently tricky is that the newest version (V2) is only available with an ITU TIES account.  However, we cite V1, and that can be downloaded from above page.  One will be able to download V2 from the same link as soon as the pre-publication period for V2 ends (that is: once the ITU staff has finished their editorial editing round), which should be any day now. 
> Now, do I recommend a reviewer to download the 500+ pages of H.266V1 and attempt to wrap their head around it, to review a payload format?  No!  It’s way too complex, long, and dense a document.  But for those who insist: it’s there, and available for free.  And yes, in the AVT WG there are a number of people who are very familiar with eth doc as they contributing in writing it.
>  
>     I have some of observations -
>  
>     -  Section 4.3.1 : what is the PayloadHdr type for the single NAL unit packet?
>     is this type not needed here?
>  
> Other ADs also found this confusing.  For single NAL unit packets, the NAL unit header co-serves as the payload header, and the type field values are taken from the values specified in H.266v1, section 7.4.2.2, table 5.  Let me note here also that implementers the payload format necessarily need to be familiar with at least the high-level syntax aspects of H.266 and the structure of the H.266 spec itself.  They are most likely also familiar with earlier video codecs that use the NAL unit concept, such as H.264 and H.265, and their respective payload formats including RFC 3984 and RFC 7798.  All these formats share the same mechanism, so we expect that implementers will most likely be familiar with it.
> Regardless, as pointed out to other ADs also, we plan to add informative language to clarify the above.
>  
>     -  Section 7.3.2 : actually contains both unicast
>     and multicast considerations but in the beginning of the section only mentioned
>     unicast.
>  
> Francesca pointed that out as well.  The problem is a clerical error with the section numbering—what is currently 7.3.2.4 should be 7.3.3.  AFAIK, Offer/Answer is not defined for multicast.  We will correct the section numbering.
>  
> -  Section 10 : I think here AVPF (RFC 4584) is the proper profile
>     example than 3551. But that for this section.
>  
> Per IETF dogma, congestion control needs to be applied to any RTP session regardless of any of the defined profiles.  (The real world does not necessarily concur in my experience, but that’s another story.). Insofar, what we wrote is not wrong.  However, we can (and should) add a reference to AVPF here as well.
>  
>