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/
Preliminaries (Chairs, 10 min)
Note Well, Note Takers, Agenda Bashing, Draft status
Recently published RFCs: RFC 9443 (QUIC multiplexing)
RTP Payload Format for Essential Video Coding (EVC) (S. Wenger, 10
min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc
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.
https://mailarchive.ietf.org/arch/msg/avt/iMGw7cfEBHWuq2LV1IEXQ-85GCk/
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
RTP Payload Format for the SCIP Codec (D. Hanson & M. Faller, 10
min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip
-- 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
-- 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.
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?
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".
Mathias: Maybe we need an application layer message instead of
STOP_SENDING?
Action item: Authors to continue to work on closing open issues.
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).
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.
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/