Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

Notes: Spencer, with much-appreciated asists from Stephan and James

Virtual Interim Agenda

Date: Tuesday, May 23, 2023
Time: 09:00 - 11:00 Pacific Time

Notes:
https://notes.ietf.org/s/notes-ietf-interim-2023-avtcore-02-avtcore

Meeting information:
https://datatracker.ietf.org/meeting/interim-2023-avtcore-02/session/avtcore

Remote instructions:
https://meetings.conf.meetecho.com/interim/?short%3Dec888cd7-4423-4a49-aabb-a93c9d9ade05

Slides:
https://docs.google.com/presentation/d/1VtKDEvetEF8Q2H2bJreCAiiVo7CHMXcqjCkjtU_MCko/

Agenda

1. Preliminaries (Chairs, 10 min)
   Note Well, Note Takers, Agenda Bashing, Draft status

   Spencer was dragooned as HedgeDoc note-taker, after muttering that
   meeting participants should be following along with the HedgeDoc
   note-taker and making corrections while the events are clear in our
   minds. We shouldn't be relying on one person to capture everything.
   Accurately documenting working group discussions is a working
   group responsibility, in Spencer's humble yet correct opinion ...
   \:roll_eyes: :face_exhaling:

   The agenda escaped being bashed

   TODO: Bernard needs to review the EVC payload draft.

2. RTP Payload Format for SCIP (M. Faller, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip/ballot/

   Authors think they have addressed the review comments, and are
   waiting for IESG reviewers to confirm, but so far, no response to
   emails.

   Bernard has read the SCIP documentation and agrees that it is not
   necessary to read the SCIP document in order to understand how to
   packetize SCIP in RTP. But that may not be clear to IESG reviewers
   who haven't read the SCIP document.

   Roman's DISCUSS on Section 6 looks like he's asking for security
   properties.

   Bernard: The document does describe the properties that SCIP
   provides. Move that discussion to the security considerations
   section? All key management protocols send in the clear until you
   are able to turn on encryption.

   Zahed's DISCUSS asked about profiles. When using SCIP, it is
   possible to use AVP, AVPF or SAVPF. SCIP does not preclude use of
   SRTP or feedback. Maybe this needs to be stated explicitly?

   The use of the term "variable" caused confusion. This was not
   referring to "variable bitrate". It has been clarified in the -05
   draft.

   Spencer: in the Sarker DISCUSS, there is a question about a "MAY".
   Is normative language needed here? Or could we substitute "could" or
   "might"?

   Bernard: How about focusing on Zahed's DISCUSS for now. It looks
   like that DISCUSS is easily addressed.

   Spencer: It's ok to improve the document, but beware of making
   changes that we just hope will generate a response from radio silent
   ADs. One way to get a response is to put the draft on an upcoming
   telechat agenda, to capture the attention of all the ADs again.

   (Not on the call, but verified after the call - upcoming IESG
   agendas have "new" items under 2.1.1, so I assume that ADs can
   still put "returning" items on the agendas as well. Again, that's a
   fine thing to talk about with our AD)

3. Video Frame Marking RTP Header Extension (M. Zanaty, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking/ballot/

DISCUSS related to privacy of the framemarking header extension.

Decision: Add to the existing security considerations section a
discussion of privacy issues. The framemarking header extension is
intended for middleboxes, so not recommended for 1-1 calls. Applications
using video marking RTP header extension can use cryptex (RFC 9335) to
ensure against snooping.

1. RTP Payload Format for Visual Volumetric Video-based Coding (V3C)
   (L. Iliola, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-v3c/

   This is just an update for WG information.

   Jonathan: this draft is close to ready for WGLC.

2. RTP Control Protocol (RTCP) Messages for Green Metadata (Yong He, 10
   min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtcp-green-metadata

   Srinivas is presenting in Yong He's absence.

   Bernard: What happens if a request is received for temporal and
   spatial resolutions GREATER than what was negotiated in the SDP?

   Srinivas: that should be an error.

   Stephan: The draft should just describe what the receiver does -
   that works better than trying to control what the sender is doing.

   Srinivas: When the receiver receives a TSRR message with spatial
   resolution greater than the negotiated spatial resolution negotiated
   in the SDP, the receiver ignores the request.

   Jonathan: "ignoring" is tricky - you probably want to send some
   respose, so the sender won't keep retransmitting.

   Srinivas: When the receiver receives a TSRR message with spatial
   resolution greater than the negotiated spatial resolution negotiated
   in the SDP, the receiver ignores the request and will respond with a
   TSRN message with the existing spatial resolution. The receiver
   shall not process the TSRR request with a resolution greater than
   the resolution negotiated in SDP.

   Srinivas: We will update the draft based on this discussion.

3. RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 20 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

   Mathis presenting updates since Yokohama, including RTCP and RFC
   7667 tables, CC terminology, absence of BCP recs for CC, rearrange
   of CC section, STOP_SENDING, error codes

   Bernard: What is the purpose of STOP_SENDING? Is it just a way for
   a receiver to get the sender to send a RESET_STREAM?

   Mathis: We'd like to drop it, but feedback was we must define how to
   handle it.

   Spencer: There's been confusiion over the meaning, not saying it's
   the right way to clear the queue.

   Bernard: Is there a role for it?

   Spencer: There's a role for an RTP receiver telling an RTP sender to
   change the leading edge. If we can use STOP_SENDING for that,
   great, and if not, we need to find a way to do that, but either way
   we have to define what STOP_SENDING means.

   Joerg - We have an undetermined amount of data in QUIC due to
   potential retransmissions, I believe there is a legitimate reason
   for having this.

   Jonathan: If you're doing multiple frames per stream, what does this
   mean?

   Mathis: STOP_SENDING does not include an indication of what has
   already been received, so it's possible to cancel more media than
   necessary.

   Mathis: I think we need to stick to the behavior defined in QUIC.

4. HEVC Profile for WebRTC (B. Aboba, 10 min)
   https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-hevc-webrtc

   Bernard: Browsers are implementing support for HEVC. HEVC decode is
   now supported in Chromium WebCodecs (hardware only). Encode is a
   work-in-progress (also hardware only). HEVC support in WebRTC is
   also a work-in-progress within Chromium. This includes support for
   RFC 7798 packetization/de-packetization. However, one issue that has
   arisen is what SDP support is needed. So a draft was needed to cover
   the requirements for HEVC support in WebRTC, with a similar scope to
   what RFC 7742 does for H.264.

   Jonathan: Is this in our charter? Maybe, because the RTCWEB WG is
   closed.

   Bernard: I brought it here, because the expertise is here (this WG
   produced RFC 7798)

   Jonathan: We also need to think about other things that are unique
   for HEVC.

   Bernard: Because support is hardware only, it's necessary to take
   into account what features chipsets implement. For example, HEVC
   screen content coding is typically not supported in hardware, so we
   have not included that in the WebCodecs encoding options.

   Jonathan: What about bugs in chipsets?

   Bernard: That is also an issue. For example, there are hardware
   decoders that do not support spatial references. So even if the
   encoder supports spatial scalability, a hardware decoder may not be
   able to decode it. So we had to make it possible to discover if the
   decoder supported spatial references within the Media Capabilities
   API.

   Jonathan: It would be a good idea to send a note to the RTCWEB WG
   mailing list, pointing to the draft and asking for feedback.

5. RTP Payload Format for SFrame (P. Thatcher, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-sframe-enc
   https://github.com/pthatcher/avtcore-rtp-sframe

   At the last meeting, we discussed a way forward for RTP
   packetization of SFrame. I was asked to write a draft, which I have
   now posted on github (yesterday). People should look at it...

   How are sequence numbers handled? This wasn't on the slide because
   Peter forgot, but he does know about it. ...

   Bernard: Given the discussion about SCIP, it would be good to have
   an introductory section going over the architecture and how things
   work.

   Jonathan: Having the SFrame document be a public document will make
   it easier for the IESG.

   Peter: Should we adopt the draft?

   Jonathan: A day-old draft is maybe a LITTLE early to adopt ... deal
   with open questions first?

   Bernard: You need to submit the draft to the I-D archives, and let
   people read it first.

6. P2P QUIC (P. Thatcher, 10 min)
   https://w3c.github.io/p2p-webtransport/
   https://w3c.github.io/webrtc-ice/

   Peter: Chrome had a P2P QUIC Origin Trial in 2019. The Origin Trial
   provided support for datagrams as well as QUIC streams. It used
   gQUIC, so it didn't support RFC 7983bis multiplexing. But it did
   support peer-to-peer operation of QUIC over ICE. The QUIC
   connections can be used for any purpose: transport of data, media,
   etc.

   Peter: P2P QUIC does not utilize QUIC connection migration, but lets
   that be handled by ICE (same as in WebRTC data channel). P2P QUIC
   uses self-signed certificates, similar to DTLS, so the SDP looks
   similar.

   Peter: P2P QUIC envisages use of the "q2q" ALPN. Is there a reason
   to have another ALPN for RoQ? I don't think it's necessary.

   Bernard: Is it possible for RoQ to run over P2P QUIC? From a
   protocol perspective, the answer is probably "yes". But it is not
   clear to me from an API perspective. RoQ envisages tight integration
   of RTP with the QUIC stack. That integration would not be possible
   in a browser where the QUIC stack is typically in a separate
   process. Does the WebTransport API + P2P QUIC API provide the
   information and control that RoQ needs?

   Mathis: Current RoQ draft uses the rtp-mux-quic ALPN.

   James: Don't think the APLN is the right place to distinguish
   between client-server and P2P?

   Bernard: P2P QUIC can't reuse the WebTransport ALPN because the
   protocol is different (raw QUIC versus WebTransport over HTTP/3). Or
   are you saying to just use the QUIC ALPN?

   Spencer: Don't worry about conflicting with the SDP for RoQ draft,
   because that doesn't describe much of the functionality.

   Peter: In terms of SDP, we start with UDP/QUIC (for P2P QUIC). Then
   for RoQ we can have UDP/QUIC/RTP.

   Bernard: A similar issue has come up in WISH. WebRTC DataChannel SDP
   does not describe what is running on top of the datachannel. So the
   question has arisen about how you could define what is transported
   on top. For example, there are streaming applications that transport
   CMAF over data channel.

   Peter: For P2P QUIC, it would be useful to have support for realtime
   congestion control algorithms such as Google Congestion Control
   (gcc). For that, we would need the QUIC timestamp extension, so we
   can calculate the one-way delays. I think we should define real-time
   congestion control once, not just for RoQ

   Spencer: I agree

   Jonathan: If it's not RTP-specific, it's not in scope for AVTCORE

   Spencer: I understand. Perhaps it would be in scope for the proposed
   Congestion Control Working Group (CCWG), but as of last week, I
   don't think that charter had been approved.

   Jonathan: Perhaps it should go to the QUIC WG?

   Spencer: I think the QUIC WG would have to recharter for that. But
   the point for this meeting is that Peter has asked a good question,
   and it's up to us to answer it.

   Bernard: Maybe bring it to DISPATCH?

   Jonathan: If that's not in scope for AVTCORE, the RoQ folks should
   keep an eye on that.

7. Wrapup and Next Steps (Chairs, 10 min)

   No discussion for this agenda item