Audio/Video Transport Core Maintenance (avtcore) Working Group

CHAIRS: Jonathan Lennox
Bernard Aboba

IETF 117 Agenda
Location: San Francisco, USA
Session: Wednesday, Session II
Room: Plaza A

Date: Wednesday, July 26, 2023
Time: 13:00 - 15:00 Pacific Time

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

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

   Recently published RFCs: RFC 9443 (QUIC multiplexing)
   Status of post-pubreq documents:
   draft-ietf-avtext-framemarking: -15 submitted, state moving to
   "Review needed"
   draft-ietf-avtcore-rtp-scip: 1 DISCUSS comment, discussion today

2. RTP Payload Format for Essential Video Coding (EVC) (S. Wenger, 10
   min)
   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc

   • Draft has completed WGLC with no objections or outstanding
     issues. Summary posted on May 2, 2023.
   • Any additional issues not addressed? No additional input from
     the WG.
   • Draft PubReq sent to the mailing list on July 22, 2023
   • Authors and contributors have confirmed in email to the mailing
     list their willingness to be listed as well as their BCP 78/79
     obligations.
   • media-types review request sent to the media-types mailing list
     by Stephan Wenger.
   • Review by Roni Even recommended change control by AVTCORE.
     Comment addressed by Stephan Wenger.
   • Given that the media-type allocation is based on H.266
     allocation (iana.org/assignments/media-types/video/H266),
     media-type registration request appears to be ready.
   • Discussion of IPR declaration sent to the AVTCORE mailing list.
   • Goal of MPEG is to keep the baseline profile royalty-free.
   • Given the IPR declaration, are there any objections in the
     AVTCORE WG to proceeding to publication?
   • No objections from WG to proceeding to publication.
   • Discussion of availability of ISO EVC specification.
   • ISO EVC specification is behind a paywall, but Stephan Wenger
     will provide a copy to reviewers.
   • Copy was provided to Bernard for his publication review. Stephan
     will also provide a copy to other reviewers, including
     Directorates, IESG, etc.

• Action item: Bernard to complete Publication Request based on WG
  discussion.
  Item completed on July 30, 2023. See:
  https://mailarchive.ietf.org/arch/msg/avt/iMGw7cfEBHWuq2LV1IEXQ-85GCk/

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

   • GStreamer plugin implementation in progress. Should be ready by
     November 2023.
   • Specification is stable and mature.
   • Action: Request to go to WGLC.

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

• Document in State "Version Changed - Review Needed"
  Ballot comments:
  https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/ballot/

• DISCUSS by Z. Sarker. R. Danilyw DISCUSS changed to ABSTAIN.

• Dan Hanson and Mike Faller describe the changes made in -05,
  submitted on March 29, 2023.

• Mike Faller: What additional changes are required to address the
  DISCUSS and other IESG comments?

• Murray: May be a few days for Z. Sarker to reply

• Mike Faller: Delays due to reviewers not understanding context. SCIP
  is already deployed. This belongs in the IETF so OEMs can integrate
  SCIP into devices. Problem is that SBCs and other devices are
  attempting to parse (and in some cases, modify) the payloads and
  this is breaking SCIP.

• Bernard: SCIP was the first transport-independent E2E payload
  encryption scheme. The definition of "endpoint" is different than in
  PERC and SFRAME (a conferencing server is an "endpoint" in SCIP, but
  not in PERC or SFRAME). Aspects of SCIP (such as the SDP negotiation
  approach) are being considered for adoption in other approaches,
  such as the SFRAME RTP packetization effort. So SCIP can be
  considered influential.

• Bernard: Ballot comments include statements about SCIP document
  availability, as well as the IETF policy on normative references
  that seem odd. The IETF policy on normative references is that the
  references need to be made available to reviewers on request. They
  don't have to be available for free on the open web. For example,
  see RFC 7241 ("The IETF/IEEE 802 Relationship") Section 3. The SCIP
  authors have agreed to provide documentation for normative and
  informative references to reviewers upon request.

• Murray: We couldn't get access to the document at time needed.
• Bernard: The IESG didn't request the SCIP documents, in order to
  verify that the SCIP RTP payload specification was implementable
  without access to the informative reference (SCIP protocol
  documentation).
• Mike: There was complaints that they weren't supplied the document
  within an hour.
• Murray: Did those complaints come from the IESG?
• Bernard: No. Early on, there were delays in responding to document
  requests. But this was ironed out. When I requested the
  documentation, it was provided within 72 hours.
• Murray: The question is "can I review this document"? If not, how
  can I do my job?
• Mike: The SCIP RTP payload document contains contact information for
  obtaining the latest copy of the SCIP documentation. [Section 8,
  email address is ncia.cis3@ncia.nato.int].
  Older versions of the SCIP documents are available online.

[See: https://www.iad.gov/SecurePhone/ Documents include:
SCIP protocol documentation, dated March 15, 2011
SCIP 214 1 Rev. 1.0 (July 12, 2011)
SCIP 214 2 Rev. 1.0 (July 12, 2011)]

• Action: Murray to provide a list of those from IESG whom require the
  specification

• Mike: As an example, Cullen Jennings looked at the document and
  concluded the SCIP documentation wasn't needed.

• Murray: Other RTP payload documents contain normative references to
  codec specifications. Why is SCIP different?

• Bernard: Other codec specification include normative references
  because the RTP packetizer/depacketizer needs to understand the
  codec formats to packetize them. The SCIP RTP payload format is
  different - the packetizer/depacketizer treats SCIP as an opaque
  blob.

• Note: SCIP includes a negotiation and key management phase, after
  which keys are pushed down and the payloads are encrypted, making
  them opaque. At all phases of the SCIP state machine, the SCIP layer
  provides payloads to the RTP packetizer which are tailored to the
  MTU, so the packetizer only needs to place the SCIP fragments
  provided into the RTP payload, it does not need to parse them.
  Similarly, the jitter buffer/depacketizer needs to handle reordering
  and recovery via RTX or FEC, then hand the fragments to the SCIP
  layer. It only needs to parse the RTP header to do this, it does
  need to parse the SCIP fragments. The authors need an RFC is because
  middle boxes have been attempting to parse the SCIP payloads and
  modify them. This breaks SCIP. So we have a classic "protocol
  ossification" problem here.

• Bernard: The authors have resisted requests to put details of the
  SCIP packet format into the RTP payload specification. There is a
  good reason for this. It is not because SCIP is "proprietary" or to
  prevent the IESG from accessing the specification. The SCIP protocol
  specifications are non-normative because correct implementaton of
  SCIP on the endpoints as well in middle boxes REQUIRE that SCIP
  payloads be treated as opaque blobs that MUST NOT be parsed or
  modified.

• Mike: If endpoints or middle boxes were to parse SCIP payloads and
  not treat them as an opaque blob, then when the SCIP protocol is
  revised, the revision cause breakage in implementations of the SCIP
  RTP payload on endpoints or in middle boxes. This is what we are
  trying to avoid by publishing an RFC.

• Note: Other IETF WGs are also challenged by "ossification". The IETF
  QUIC WG has spent a good deal of effort on "bit greasing" in order
  to prevent protocol ossification. Ossification is not just a middle
  box issue. RFC 5716 (EAP-TLS) experienced ossification on the
  endpoints. EAP-TLS is a protocol that encapsulates TLS in EAP. RFC
  5716 was intended to be TLS-version independent, and it was
  implemented with TLS 1.0, 1.1 and 1.2. However, RFC 5716 contained
  text and examples that were too low level, getting into details of
  the TLS protocol that were invalidated by the design of TLS 1.3.
  This required the EMU WG to do a major rewrite in order to support
  EAP-TLS 1.3 (RFC 9190). However, RFC 9190 contains examples and text
  specific to TLS 1.3, so it is conceivable that yet another rewrite
  might be needed for future versions of TLS. The lesson is that
  protocols encapsulating evolving cryptographic protocols like TLS or
  SCIP need to be careful about providing too much detail about the
  protocol being encapsulated, if the encapsulation process doesn't
  actually need that information.

• Spencer: IESG have a 2 week cycle for reviews, IESG should consider
  something for the shepherd's review template covering access to
  non-public references?

• Stephan: References like the ISO EVC specification are not-publicly
  available. This has never been an issue before. Why is it suddenly
  not good enough to provide references on request as we have been
  doing for decades?
• Magnus Westerlund: This will remain a problem for review teams.
• Stephan: Why? All the reviewers need to do is to send an email to
  request access.

• Murray: This issue comes up enough with downref's we have rules for
  unaccessible documents, this is not the first document.

• Mike: RFC 8817 (RTP Payload Format for Tactical Secure Voice) has
  normative references to [MELP] and [MELPE]. Those references are
  available on request, similarly to SCIP. Why is the IESG treating
  the SCIP RTP payload format document differently?

• Murray: The IESG membership has turned over and there are different
  Area Directors.

• Lucas Pardue: Good reviews are super important, people can only
  carve out so much time.

• Action item: Include information on how to obtain references in
  future Publication Requests such as for the EVC RTP payload format.

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

• Bernard: Do you think you need to negotiate Streams and Datagrams?
  Or are we expecting the RTP over QUIC receiver to support an RTP
  stream arriving over a reliable stream or datagrams or some mixture
  of both? Having a stream arrive over a mixture of a reliable stream
  AND datagrams seems like it could complicate the jitter buffer
  implementation. You might want video to flow over frame/stream and
  audio over datagrams, but would you ever need a single audio or
  video stream to use both? Seems like needless complexity.
• Spencer: We're trying to write generalised text based on QUIC now
• Bernard: Do you expect CLOSE_STREAM to be used with RTP over QUIC?
• Mathias: Could a sender use CLOSE_STREAM in response to
  STOP_SENDING? The problem with STOP_SENDING is that the sender
  does not know what frame is being referred to if multiple frames are
  being sent on the stream. So it might want the frame it is currently
  sending to be delivered reliably, then close the stream.
• Lucas: RFC 9000 requires the sender to send a RESET_STREAM in
  response to STOP_SENDING.

• Mathias: Maybe we need an application layer message instead of
  STOP_SENDING?

• Action item: Authors to continue to work on closing open issues.

1. Peer-to-Peer QUIC (P. Thatcher, 10 min)
   https://datatracker.ietf.org/doc/html/draft-thatcher-p2p-quic

• Peter: ALPN is "q2q"
• Lucas: ALPNs are for application layer protocols.
• Peter: Peer-to-Peer QUIC is an application layer protocol, isn't it?
• Lucas: Not necessarily.
• Bernard: QuicTransport defined an ALPN.

• Lucas: No it didn't!

• Explanation: The term "QuicTransport" has two distinct meanings.
  RTCQuicTransport object implemented in the P2P QUIC Origin Trial
  implemented raw gQUIC over ICE. While the API specification defined
  the ALPN as "q2q", this was not implemented. The QuicTransport
  protocol was a client/server application layer protocol that
  included the exchange of key/value pairs as described in:
  https://datatracker.ietf.org/doc/html/draft-vvv-webtransport-quic#page-9

  For QuicTransport the ALPN was "wq-vvv-01".

• Peter: For P2P QUIC, authentication is similar to DTLS. That is,
  self-signed certificates are used in QUIC connection setup, and then
  the fingerprints are sent in signaling and are verified to
  correspond to the certificates exchanged in the QUIC connection
  setup. In terms of requirements for P2P QUIC, we believe it is
  important to be able to support both data and media exchange with a
  single ALPN, just like in WebRTC. Also, it is important to be able
  to handle frame/stream transport in a better way than can be done in
  WebTransport today. To address these issues, we are proposing a
  "multiplexing ID" in P2P QUIC.

• Mathias: Why can't we have multiple ALPNs? You could have on ALPN
  for media and another one for data...

• Peter: WebRTC was designed to be able to send data and media to a
  single port with one ALPN. Using multiple ALPNs would create
  complexity and also make it difficult to have both media and data
  use a single congestion controller. This was a problem in WebRTC
  where data and media used different congestion control algorithms:
  SCTP (NewReno) and media (gcc). If we send both media and data over
  QUIC, we have the opportunity to fix this, by using low-latency
  congestion control for both data and media. Today with SCTP, it is
  possible for data to starve media, but with unified congestion
  control this wouldn't happen. Requiring separate ALPNs would mandate
  different QUIC connections for data and media and we would have the
  data and media competing with each other. For example if you had one
  QUIC connection with data and another with media, they would tend to
  equalize the bandwidth. But you'd probably want to limit the
  bandwidth used by a background file transfer so it didn't starve out
  video or audio. You can't make that happen with
  separate ALPNs.

  Here is an example of what the SDP looks like.

• Bernard: Your SDP includes the line "a=mid:1". Is this referring to
  the "multiplexing ID" or to the MID defined in WebRTC? In the
  UDP/QUIC generic line you have "a=quic-options:multiplexing-id"
  which I assume is referring to the multiplexing ID?

• Peter: The "a=mid" lines are referring to the "multiplexing ID".
  Sorry for the confusion.

• Bernard: With respect to the line "m=audio 9 UDP/QUIC/RTP/AVPF 99"
  line... It seems like you might want different transport for Audio
  (where datagrams would make sense to transport a codec like Opus
  with FEC) than Video (where you could use frame/stream reliable
  transport). Is there a way to specify whether media is being sent
  over datagrams or reliable streams (or some mixture of both)?

• Peter: In this SDP example, that info isn't there.

• Peter: here is my analysis of Marten's 3 modes (see next
  presentation)

  Mode 1: ICE + QUIC (just like my draft, compatible with the P2P QUIC
  APIs)

  Mode 2: ICE + QUIC with "relay first"
  ICE with "relay first" has been implemented. Uses a TURN candidate
  to bring up the ICE connection quickly, then continues trying other
  candidate pairs to find a "less expensive" pair. Can also use "TURN
  Mobility" (RFC 8016) to quickly re-establish connectivity after an
  interface goes down.
  Might be compatible with envisaged APIs. Depends on how "relay
  first" is done.

  Mode 3: ICE over QUIC.
  Uses QUIC for connectivity checks instead of STUN. Envisaged Web
  API may need to be changed considerably.
  Potential problems? large ICE checks, check before handshake.

  Action items: Peter to work with RoQ authors and Marten Seemann (see
  next presentation).

1. Using QUIC to traverse NATs (M. Seemann, 15 min)
   https://datatracker.ietf.org/doc/html/draft-seemann-quic-nat-traversal

   Purpose: To use QUIC in a P2P setting (such as WebRTC over QUIC and
   other protocols)

Mode 1: ICE over QUIC. Problem: many round trips.

Mode 2: Use a proxied QUIC connection (e.g. CONNECT-UDP), then migrate.

• Peter: What if UDP is blocked? TURN approach accomplishes the same
  thing but can succeed even where UDP is not available.

Mode 3: Leverages QUIC path migration.

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

• Bernard: Support for HEVC encode/decode in browsers is hardware-only
  (no software fallback).

• Implementation of HEVC decode (WebCodecs) is now behind a flag in
  Chromium. Progress on HEVC encode and decode (WebCodecs) in Safari
  17 preview.

• PRs for support of HEVC packetization/depacketization
  (RFC 7798) in both WebKit and Chromium.

• To ship HEVC support in WebCodecs and WebRTC we will need Web
  Platform Tests (WPT). For WebRTC, WPT tests will require an SDP
  profile. That is what this draft is looking to provide.

• Action item: Jonathan to issue a "Call for Adoption"

1. RTP Payload Format for SFrame (P. Thatcher, 10 min)
   https://datatracker.ietf.org/doc/html/draft-thatcher-avtcore-rtp-sframe

• Peter: At the last meeting, I presented a proposed approach and the
  feedback was that I should write a specification and I have now done
  that.
• Jonathan: Does WG approve of the approach taken in this document?
• Multiple "thumbs up" in the chat.
• Action item: Chairs to issue a "Call for Adoption".

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