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.
     -- 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.
     -- Since the media-type allocation is based on H.266 allocation
     (iana.org/assignments/media-types/video/H266), media-type
     registration has now gone through multiple reviews and appears
     to be ready.
   • IPR situation.
     -- IPR declaration announcement sent to the AVTCORE mailing
     list.
     -- Goal of MPEG is to keep the baseline profile royalty-free.
     -- Given the ISO IPR goal and the IETF 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. Posted to the mailing list on July 30, 2023. See:

     https://mailarchive.ietf.org/arch/msg/avt/iMGw7cfEBHWuq2LV1IEXQ-85GCk/

3. 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 item: Request to go to WGLC.

4. 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

• Discussion of IETF policy on normative references
  -- 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. SCIP encapsulates codec payloads (like a tunneling
protocol) but is not a "codec" like HEVC or VVC. 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 and packetization of "opaque
blobs") 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 off. The IETF policy (and the AVTCORE WG policy) is that 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 to reviewers upon request. Other payload formats
(such as the EVC RTP payload format) also have normative references that
are not available free of charge, because the ISO EVC specification is
behind a paywall (but Stephan can provide it to reviewers).

-- Murray: We couldn't get access to the document within the 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 were 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 item: Murray to provide a list of those from IESG who require
  the specification.

• Discussion of how the SCIP RTP Payload format differs from other
  codec payload formats

  -- Bernard. There is a good reason why the SCIP documents are a
  non-normative reference. It doesn't have to do with document
  availability. It has to do with the nature of SCIP. If the IESG
  doesn't understand this, they'll just waste time reviewing the SCIP
  documentation.

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

  -- Bernard: SCIP isn't a conventional codec. It is a tunneling
  protocol. In conventional RTP payload specifications, the RTP
  packetizer/depacketizer needs to parse the RTP payloads, in order to
  reformat the bitstream or fragment frames between packets. The SCIP
  RTP payload format is fundamentally different, because it specifies
  the tunneling of SCIP within RTP. The SFrame RTP payload format will
  operate in a similar way.

  -- Mike: Cullen Jennings looked at the document and concluded the
  SCIP documentation wasn't needed.

  -- Bernard: It isn't needed, because in the SCIP RTP payload format
  the packetizer/depacketizer treats SCIP as an opaque blob. This
  isn't just for the encrypted messages sent after key negotiation.
  Even the initial negotation messages (sent prior to key
  installation) need to be treated like opaque blobs.

  -- The SCIP packetizer/depacketizer acts like a tunneling endpoint.
  The SCIP layer provides payloads to the RTP packetizer which are
  tailored to the MTU, and the packetizer places the SCIP fragments
  into the RTP payload without parsing or modifying them.

  -- The jitter buffer/depacketizer handles reordering and recovery
  (RTX/FEC) but not concealment. The SCIP fragments are handed in
  order to the SCIP layer. The depacketizer needs to parse the RTP
  header, but not the SCIP fragments.

• Murray: Why is the IETF standardizing an RTP payload format for the
  proprietary SCIP protocol?

  -- Mike: SCIP isn't proprietary, earlier versions of the
  specification are available for download on the Internet and the
  latest specifications are available on request. Section 8 includes
  the email address to request access to the SCIP specification.

• Why are the authors going for Proposed Standard rather than
  Informational?

  -- Bernard: E2E encryption schemes like SCIP operate fundamentally
  differently from conventional RTP payload formats. Middle boxes are
  treating SCIP like a conventional codec, attempting to parse the
  SCIP payloads and modify them like would be done for other codecs
  like G.711. This will break any E2E encryption scheme (including
  SFrame), not just SCIP.

  -- Bernard: The authors don't want to add more details of the SCIP
  message format into the specification. This is not because SCIP is
  "proprietary" or because they are trying to prevent the IESG from
  accessing the specification. Correct implementaton of SCIP on the
  endpoints and middle boxes REQUIRES that SCIP payloads be treated as
  opaque blobs that MUST NOT be parsed or modified. So if the RTP
  payload format implementation is attempting to parse SCIP, it is
  doing something wrong. The authors are attempting to specify a
  tunneling protocol, not a conventional RTP payload format.

  -- Mike: The SCIP WG wants to be able to evolve SCIP. If the
  packetizer/depacketizer or a middle box parses SCIP, it will break
  if the SCIP message format changes, even if the payload isn't
  modified. Providing "more information" on the message format will
  just make things worse. Middle boxes will just take that information
  and use it to parse the payloads!
  -- Bernard: SCIP messages need to be treated as an opaque blob.
  This is a "protocol ossification" problem.

  -- [Note: A similar lesson can be learned from the evolution of
  EAP-TLS, which was first specified in RFC 2716, and revised in RFC
  5716. EAP-TLS encapsulates TLS in EAP. EAP does not need to parse
  TLS to transport it. RFC 5716 intended to be TLS-version
  independent, but the authors made a mistake by including text and
  examples that got into the details of TLS, rather than specifying
  EAP-TLS as a tunneling mechanism.

  • RFC 5716 was adequate for enabling EAP-TLS to function with TLS
    1.0, 1.1 and 1.2. Then TLS 1.3 came along, and the examples and
    much of the text was invalidated. The EMU WG had to do a major
    rewrite to specify EAP-TLS 1.3 in RFC 9190.
  • Unfortunately, it is possible that RFC 9190 will require yet
    another major rewrite for a future TLS version, because it
    contains examples and text specific to TLS 1.3!

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

  -- 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: All the reviewers need to do is to send an email to
    request access.

  • Murray: This issue comes up enough with downrefs 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.

• Authors need to clarify the fundamental nature of SCIP, that it is a
  tunneling protocol, not a conventional "codec".

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.

• Peter: 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 item: 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.

2. 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". Message sent
  on August 4, 2023:
  https://mailarchive.ietf.org/arch/msg/avt/9lAZUxOn6ZHfYCQpshpEwcHz-Z0/

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)