Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

IETF 116 Agenda
Location: Yokohama, Japan
Session: Tuesday Session II
Room: G314 - G315, 3F

Date: Tuesday, March 28
Time: 00:00 - 02:00 Eastern Time
04:00 - 06:00 UTC

IETF 116 info: https://www.ietf.org/how/meetings/116
Meeting link: https://meetecho.ietf.org/conference/?group=avtcore
Notes: https://notes.ietf.org/notes-ietf-116-avtcore
Slides:
https://docs.google.com/presentation/d/1LG-NOLbH3drMPki4JQuW5vAgljBYLky_Zs6nwnVTVlc/

Note taker and onsite chair: Harald Alvestrand

1. Preliminaries (Chairs, 10 min)
   Note Well, Note Takers, Agenda Bashing, Draft status
   4 RFCs published, rfc 7983bis now in RFC Editor queue.
   One in RFC Editor queue (vp9) with missref (framemarking) now
   resolved.
   4 new drafts adopted

2. RTP Payload Format for the SCIP Codec (M. Faller, 10 min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip
   Dan Hanson presenting.
   Draft -05 distributed by email, to be submitted after the meeting.
   Changes suggested at the meeting on feb 23 have been incorporated.
   Main point is that network devices MUST NOT filter or modify
   Packetizing and depacketizing procedure is made clearer.
   Figure added, showing the architecture. Packetization is handled
   within
   the underlying codec, then passed to the SCIP layer which encrypts
   them.
   SCIP also provides its own messages, which are in cleartext prior to
   key
   negotiation, and are encrypted afterwards. SCIP packetizes the
   control
   traffic as well and passes this to the RTP packetizer.
   Roman (discuss holder): still don't understand why there can't be a
   normative
   reference to SCIP describing the content.
   Bernard: The VVC RTP payload format had the VVC bitstream spec as a
   normative
   reference. However in this case, the payloads are (with the
   exception of the
   initial key negotiation) encrypted. This means that there is nothing
   for the
   packetizer to parse, it just places the opaque blobs handed to it by
   the SCIP
   codec into the RTP payload field. Similarly, on reception the RTP
   de-packetizer
   hands the opaque payloads to SCIP which decrypts them.
   Dan: Since the packetizer and depacketizer aren't parsing the opaque
   payloads,
   there was no need for a normative reference to the SCIP
   specifications. There
   is nothing in the SCIP specifications that needs to be understood by
   the
   packetizer and depacketizer, or by intermediaries. That is the major
   point of
   the document - intermediaries have been attempting to modify the
   payloads, with
   disasterous results. For the specification to operate correctly, the
   payloads
   must be treated as opaque. We have discussed this in multiple
   meetings.
   Decision: Authors will publish the -05 document and ask for IESG
   feedback.

3. RTP Payload Format for Essential Video Coding (EVC) (S. Wenger, 10
   min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc
   Stefan Wenger: want to remind people that this draft is still
   around. We
   had suspended work on it while completing work on VVC, so that we
   could
   base the EVC document text on the published VVC RTP Payload
   specification (RFC 9328).
   From there we removed text referring to features (such as spatial
   scalability) that
   VVC supports but EVC does not. Since EVC is a subset of VVC, once
   the feature set
   was scaled back we were able to produce a draft ready for WGLC.
   -03 was technically ready for WG Last Call, an -04 is coming with
   some
   editorial improvements but no changes affecting bits on the wire.
   Authors request WGLC on -04. Chairs agree that this is appropriate.

   Bernard volunteers to be document shepherd, and will start WGLC once
   -04 is submitted.

4. RTP Payload Format for Visual Volumetric Video-based Coding (V3C)
   (L. Ilola, 10 min) (13:39)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-v3c
   Version -01 missed the deadline, will be out shortly. No technical
   or normative changes.
   Authors are calling for technical reviews of the document.
   3GPP work wants to refer to this document; their practice is to not
   refer to
   IETF documents that haven't reached Last Call.
   Next action: Chairs will review doc, more reviewers encouraged.

5. RTP over QUIC (M. Engelbarat, J. Ott, S. Dawkins, 30 min) (13:46)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic

   We will discuss the major open issues. Expect an -03 version of the
   document to issue after the meeting.
   With respect to congestion control, the current direction is to
   phrase things as guidance rather than
   requirements. RMCAT produced experimental specifications, so there
   are no low latency congestion control
   algorithms at BCP or Proposed Standard yet. In some cases, rate
   control or even congestion control behavior could
   be application-specific. So we focus on guidance about what to look
   for in CC.
   Discussing stream-per-frame and stream-per-layer behavior with
   respect to STOP_SENDING sent by a receiver.
   This requires the receiver to know the stream layout. If SVC layers
   are sent on their own streams, the receiver
   can use STOP_SENDING to unsubscribe from a layer as well as all
   layers that depend on the unsubscribed layers
   (since those layers will no longer be decodable).
   Some question about how a sender should interpret STOP_SENDING. Is
   it meant to apply only to a particular frame?
   Bernard: STOP_SENDING applies only to a stream, it is not an
   application layer construct.
   Jonathan: What happens if the receive sends a STOP_SENDING and the
   sender has already begun to send the next frame?
   Bernard: The sender can't stop sending on a stream that has already
   been closed. But if the stream is still open
   and the sender is sending another frame on that stream, it can stop
   sending that.
   Peter Thatcher: After the sender receives the STOP_SENDING, should
   it open another stream and keep sending?
   Bernard: In the absence of an indication from the receiver that it
   has lost interest in a source (e.g. a PAUSE),
   the sender has no reason to stop sending. If the goal is to cause
   the sender to drop a layer, the question is
   whether this should be handled at the QUIC layer (via STOP_SENDING)
   or via an RTCP message (e.g. TSRR)

   There is a PR in progress that contains tables of RFC 7667
   topologies and RTCP packet/feedback types,
   and evaluates how the same things can be done with QUIC.
   More feedback invited, no specific action at this time.

6. RTP Control Protocol (RTCP) Messages for Decoder Energy Reduction
   (S. Gudumasu, 10 min) (14:32)
   https://datatracker.ietf.org/doc/html/draft-gudumasu-avtcore-decoder-energy-reduction

   Presentation of message format. Not clear if asked-for rates are
   achievable.
   Seeking support for adoption of the draft, which extends the Green
   Metadata document.

7. RTP Payload Format for SFrame (P. Thatcher, 20 min) (14:46)
   https://datatracker.ietf.org/doc/html/draft-ietf-sframe-enc
   Reference: draft-ietf-sframe-enc-01
   At a previous meeting, we discussed the problem of fragmentation of
   an RTP over QUIC packet when
   translating to RTP. This requires codec-specific knowledge in the
   translator.

   For SFrame, Peter, Youenn and Jonathan Lennox are propsing the
   following for the RTP Payload Format:
   a. Use SDP similar to SCIP (e.g. audio/sframe 48000, video/sframe
   90000). Open question how the underlying
   codec is negotiated since SFrame (unlike SCIP) does not have its own
   codec negotiation messages.
   b. Instruct the underlying codec packetizer to use an "infinite MTU"
   (similar to RTP over a QUIC stream).
   c. Apply SFrame to the RTP payload.
   d. Carry fragments of the "big RTP payload" within the sframe media
   type.
   e. RTP packets containing the fragments carry fields from the "big
   RTP" frame. Do all the RTP header extensions need to be repeated in
   each packet?

   What do people think?
   Harald Alvestrand: This seems workable.
   Magnus Westerlund: I think you should go ahead and write it up.

   Next action: Write the draft, and discuss on the list.

8. Wrapup and Next Steps (Chairs, 10 min) (15:01)