CHAIRS: Jonathan Lennox
Bernard Aboba
IETF 119 Agenda
Location: Bribane, AU
Session: I
Room: P1
Date: March 19, 2024
Time: 09:30 - 11:30 Brisbane time
IETF 119 info: https://www.ietf.org/how/meetings/119
Meeting link: https://meetecho-sin.ietf.org/client/?session=31925
Notes: https://notes.ietf.org/notes-ietf-119-avtcore
Slides:
https://docs.google.com/presentation/d/1T7xa3v-jor0UblFX-83rZIHbhMvWeArJQORsam9AtKs/
Notetakers: Magnus Westerlund, Spencer Dawkins, Mo Zanaty
Preliminaries (Chairs, 15 min)
Note Well, Note Takers, Agenda Bashing, Draft status, IANA
registries
Note taker: Magnus Westerlund
Spencer gave his usual pitch for people to join the Notes page and
do corrections, and Jonathan encouraged people to look at the notes
and make sure that what YOU said was recorded correctly.
Jonathan said that the chairs have created an AVTCORE GitHub
organization.
material) be lost?
Stephan Wenger proposed that chairs makes clear what policies
that applies in regards to new postings and github discussion.
Murray asked if AVTCORE expects interactions from RTCWEB WG as they
want to shutdown.
Bernard noted an issue with JSEPbis found in the HEVC Profile
draft. This is being discussed.
Chairs mentioned the RTP Payload format IANA registry and the fact
that we haven't been able to find an RFC that actually defines the
registry. Magnus is developing a draft to close the registry and
update RFC 8088 to not require new RTP payload format to add to the
registry. Zahed asked if it was necessary to publish this document
at all. But to update RFC 8088 it would be needed. The chairs also
want to ensure that we have consensus for the change.
Galois Counter Mode with Secure Short Tags (GCM-SST) (J.P. Mattsson,
15 min)
https://datatracker.ietf.org/doc/html/draft-mattsson-cfrg-aes-gcm-ss
J.P. went through the history of GCM-SST, documented in
draft-mattsson-cfrg-aes-gcm-ss Section 1.
During standarization of AES-GCM, Ferguson pointed out two
weaknesses in the GSM authentication function.
Rogaway was critical of AES-GCM with short tags and recommended
disallowing tags shorter than 96 bits.
While Nyberg pointed out workarounds, NIST instead specified
additional requirements for use in Appendix C.
Since then, Appendix C has been criticized and NIST has announced it
will remove it.
If the Nyberg changes are adopted, is AES-GCM with short tags
sufficiently secure and performant?
Chairs of CFRG will confer about potential adoption. In CFRG, there
were comments assuming that it would
only be used for video, not audio. If CFRG review is positive and
adoption proceeds, is there interest?
Harald Alvestrand: Google Meet is interested in 32-bit tags.
Mo Zanaty: interested. But what is the hardware implementation
impact?
J.P.: This depends on how it is implemented. If there are hardware
accelerated functions, they may be used.
Jonathan: there seems to be interest in this work. The WG will wait
for CFRG to progress it before adoption.
It is good to make the interest clear to CFRG to show that it is
meaningful for them to define AES-GCM short tags.
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
The WG was updated on how a number of issues have been handled.
There are still some open issues.
Jonathan: V3C specifies rarely implemented txmodes (MRST, MRMT). If
only using SRST, things become simpler. Is it possible to leverage
EVC SDP simplifications? Is anyone using DON?
Stephan Wenger: DON has been seen in the wild, but don't include it
unless there is a real use case.
RTP over QUIC (M. Engelbart, J. Ott, S. Dawkins, 20 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-over-quic
Mathis Engelbart presented updates and open issues.
Changed doc to experimental status and added Directions for Future
work
Removed multiplexing of protocols other than RTP/RTCP.
Added discussion on coalescing RTP packets.
Future extensions can build on top of RoQ to multiplex other
protocols.
Example: data channel draft (draft-engelbart-quic-data-channels)
Uses "qdc" as the ALPN
Bernard: Why run the WebRTC data channel over QUIC? The document
requires a separate ALPN. Doesn't
that mean that data channels cannot share congestion control state
with real-time media?
Also the data channel API is poorly designed, since it delivers
messages via events (within a browser).
This means that overall receive buffers (QUIC + event queue) can
grow without exerting back pressure.
Peter Thatcher: Agree that using the current API would be a mistake
but multiplexing data and RoQ
(without introducing a distinct ALPN) would make sense.
Spencer said from his perspective, we have been thinking about
multiplexing other protocols with RoQ in general, and feedback about
specific protocols that would be usefully multiplexed with RoQ, like
the feedback Bernard and Peter are giving in this session, is
extremely helpful.
"Are we almost finished with this specification?"
There are still lots of open questions to answer in experiments. But
it is time to put down the pen.
Peter Thatcher: how far can the RoQ and SDP for RoQ specification go
if there are no solutions for peer to peer QUIC? Will the WG be
happy with a specification that only supports client to server? What
if P2P falls through the cracks between AVTCORE and QUIC WG?
Bernard: RoQ is just a transport mapping. Just because something
isn't mentioned doesn't mean it is prohibited.
RFC 3550 doesn't reference ICE.
Spencer: Confirmed with Jonathan that SDP is not blocking for WG
last call but likely is blocking PUBREQ.
Bernard: Why? RFC 3550 doesn't mention SDP. There is an informative
reference to Spencer's SDP draft, but why should that block
publication?
Spencer notes that the authors have considered further developments
that are ongoing or expected to happen and what potential impact
that can have.
Spencer pointed out that the current revision of RoQ has a new
section 13, on Future work, added at Bernard's suggestion during
the last interim. This describes things we have legitimate issues
for, but do not have a path for yet (like NAT Traversal), or do not
have experience with (like connection migration and QUIC multipath).
Spencer doesn't think it's worth blocking RoQ publication for these
topics, and they can be described in other specifications while we
are getting implementation and deployment experience.
Joerg Ott stated that we can go to WG last call before IETF 120, and
work on that feedback in a timely way. "This work has already
dragged out way too long" (Spencer notes that the individual draft
-00 was submitted in July 2021, which is far enough in the past that
one might reasonably expect we are finished).
Magnus stated that we should go to WG last call. Signalling is
seperate, and RoQ can be extended for future capabilities. Peer to
Peer is all about establishing the QUIC connection, while RoQ is
about mapping onto a QUIC connection, so it's fine for them to
progress independently.
From Lucas Pardue in Zulip: +1 WGLC soon
HEVC Profile for WebRTC (B. Aboba, 10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc
Safari TP 189 offers HEVC on a send/recv m-line, because it supports
both encode and decode, packetization and
depacketization. Chromium or FF does not yet have HEVC recv on by
default but when they do, question is whether
browsers can negotiate successfully. Does this require 2 m-lines
(send-only + recv-only) or will offering a single
send/recv m-line suffice? Assume we are talking about offering both
H.264 and H.265.
Randall Jesup feels it is ok to offer both codecs on a send/recv
m-line even if one is really recv-only. This does not violate RFC
3264. However, a problem will arise if the Answerer removes other
non-H.265 codecs so it can only receive H.265 which the Offerer
cannot send. Will that happen?
Harald says send/receive m-lines are a problem, but we must deal
with them.
Bernard: please provide any additional comments in the GitHub
threads.
RTP Payload Format for SFrame (P. Thatcher, 10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-sframe
Jonathan Lennox noted that start and end indicators in some header
extensions, like AV1 Dependency Descriptor or Frame Marking, may not
tolerate blind encapsulation.
Zahed Sarker (as individual) wants to see implementation
exerperience before progressing this.
This is a security draft, after all.
RTP Payload for Haptics (H. Yang, 10 min)
https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics
Jonathan Lennox indicated that the chairs will proceed with calling
for adoption.
RTP Payload Format for Advanced Professional Video (Y. Lim, 10 min)
https://datatracker.ietf.org/doc/html/draft-lim-apv
Stephan Wenger noted CELLAR WG does lossless codecs which may align
with this.
David Tauban asked if hardware implementation is a goal. It is.
Mo Zanaty noted that the IETF NETVC WG did not succeed, and this has
raised questions about
whether IETF is a viable SDO for development of royalty free codecs.
Most new work in this area
seems to be occurring in AoMedia which has developed a framework for
this kind of work.
Stephan Wenger would prefer a 30 year old codec to a new one, to be
confident of low IPR risk.
Cullen Jennings said an Informational RFC that documents an existing
design rather than creates a new design would be a viable path.
Zahed Sarker asks if there are people interested to participate in
this work. If so, then a WG makes sense. If no interest, then
Independent Submission makes sense.
Murray Kucherawy noted that he's handling Cellar over to Zahed on
Wednesday of this week.
Spencer noted that the model of "documenting what's out there now,
and then working on specifications for improvements" is the way
Cellar was chartered - we produced FFV1 Video Coding Format
Versions 0, 1, and 3, RFC 9043, and are now working on FFV1
version 4.
RTP Payload Format for sub-codestream J2K streaming (P. Lemieux, 10
min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-j2k-scl
Some progress on hardware implementation.
Wrapup and Next Steps (Chairs, 10 min)
Jonathan Lennox asked for doc shephards. We will not pub-req Sframe and
RTP over QUIC.
Spencer Dawkins offered to help shephard.
Altanai Bisht asked for shephard responsibilities, and may consider
volunteering. Cullen said he would be happy to help Altanai shepherd the
first document.
Jonathan Lennox noted we will have adoption calls for Haptics and Region
of Interest, and WGLC on Sframe and ROQ.