Minutes IETF113: avtcore
minutes-113-avtcore-01
| Meeting Minutes | Audio/Video Transport Core Maintenance (avtcore) WG | |
|---|---|---|
| Date and time | 2022-03-25 09:00 | |
| Title | Minutes IETF113: avtcore | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2022-03-25 |
minutes-113-avtcore-01
Audio/Video Transport Core Maintenance (avtcore) Working Group
===============================================================
CHAIRS: Jonathan Lennox
Bernard Aboba
IETF 113 Agenda
Friday, March 25, 2022
10:00 - 12:00 Central European Time (Vienna)
09:00 - 11:00 UTC
05:00 - 07:00 US/Eastern Time
Meeting URL: https://wws.conf.meetecho.com/conference/?group=avtcore
Notes: https://notes.ietf.org/notes-ietf-113-avtcore
Slides:
https://docs.google.com/presentation/d/14FG3G4v2Ps333QLC4XMeb3ZaNPvtKMsdUir85x2gsGA/
Jabber scribe: Bernard Aboba
Note takers: Stephan Wenger
-------------------------------------------------
1. Preliminaries (Chairs, 15 min)
Note Well, Note Takers, Agenda Bashing, Draft status, Liaisons
10:00
Intro slides
10:05
Agenda bash requested by Cullen Jennings: item at the end on “short tags”
10:07: VVC IPR declarations. No objections raised. Publication Request to be
sent: https://mailarchive.ietf.org/arch/msg/avt/vCws3DmeC0Ds-lWkhB6EHW_hssI/
SC29 liaison, wrong contact addres: Liaison was sent using datatracker; Stephan
to look into correcting the address.
10:10 Response to liaison from W3C web transport group.
Background: W3C WebTransport WG has use cases (such as video upload and
bi-directional realtime communications) that are potentially limited by
existing QUIC congestion control algorithms (New Reno and BBRv1/v2). They have
considered additions to the API, such as an optional argument on the desired
congestion control behavior, provided to the WebTransport Constructor. The API
does not currently supported priority.
Mo Zanaty: we had rmcat, without much success in terms of adoption. Avtcore is
unlikely to produce something better. Bernard: that could be a response. Mo,
please draft. Mo: will do. Colin Perkins: RFC 8888 describes the information
the group believed needed to perform congestion control. QUIC already provides
this information internally in connections. It could be surfaced in the
WebTransport API. The RMCAT working group developed a number of RTP congestion
control algorithms. I expect these could be incorporated into QUIC as
alternatives to its current congestion control, if there was as need, but RMCAT
isn’t chartered to do so. In the IRTF, ICCRG can provide advice about
congestion control algorithms. Bernard: please discuss on list.
Cullen Jennings: agreed with what was said, need to do APIs for browser
distinguishing between different traffic in browsers to trigger different CCs.
Can also run media over TCP, works just fine. Suhas Nandakumar: need this also
for media over quic. Mo taking the pen to draft a reply liaison with the help
of all these people here.
2. Cryptex (Sergio Garcia Murillo & Richard Barnes, 15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex
https://github.com/juberti/cryptex/issues
Presentation by Richard Barnes
Cryptex is in IETF last call until April 5, 2022. I reviewed the draft, and
found that the encryption processing was under specified. Cryptex encrypts a
portion of the RTP packet (CSRCs, Extension data and Payload), but there are
portions (the fixed header and the extension header) which are authenticated
but are not encrypted. The specification needs to clearly indicate how this is
handled. Option 1: AEAD-like. Option 2: Stream-like.
10:25 slides 17-23:
Cullen: option 1 is the way to go. Wasn’t there an IETF doc that said all
future work should use AEAD? I thought so, but can't find the document now.
Jonathan: Option 1 is how I implemented it. I think this is what we intended
all along, but we didn't make it clear.
Suhas Nandakumar: Also support option 1. Should we create the document
Cullen mentioned if it doesn't already exist?
Jonathan: maybe, but not in this WG but in security area somewhere (SAAG?)
Conclusion: option 1.
3. SCIP (Daniel Hanson, 15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip
10:32 presentation
10:37: asking next steps
Bernard: Handling of audio seems clear, but I'd like to understand the video
use cases better. Does SCIP also attempt to handle video conferencing? If so,
then a Selective Forwarding Unit will need information to know what packets to
drop or forward, just as in the E2E encrypted payload case (SFrame/SPacket)
Mike Faller: Video operates much the same as audio. SCIP establishes the
channel, after that traffic is opaque, including some negotiations in-band.
Cullen Jennings: SCIP assumes MCU style conferencing, where the MCU is an
endpoint that can decrypt SCIP. So there is no "untrusted SFU" that needs to
drop or forward opaque payloads.
Bernard: So SCIP does not support scalable video coding (e.g. H.264/SVC)?
Mike Faller: Only H.264/AVC (without temporal scalability).
Stephan: Can I understand the negotiation and media after reading
SCIP docs in normative reference.
Mike Faller: yes
Cullen: they want to have a bit pipe. Let’s give it to them.
Ted Hardie: I asked for copy of the SCIP documents, at the address that
was provided. I never got a reply - not even a "No, we can't send this
to you". So you have got a reference to documents that aren't available to
reviewers. Spec availability is an issue that needs to be called out.
As doc is a bit-pipe, an informative reference to a non-universally available
specification may be fine. But this does need to be mentioned in the
writeup.
Ted: If you are interested in providing access to the
document, please give us a procedure by which this can be accomplished.
Mike Faller: What is the next step?
Jonathan: Next step is to bring the document to Working Group Last Call.
4. RFC7983bis (B. Aboba, 15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis
10:51 presentation
Bernard: RFC 7983bis is an update to RFC 7983 Section 7, documenting
multiplexing of QUIC with SRTP, SRTCP, STUN, TURN, DTLS, and ZRTP. Note that it
is possible that changes to the QUIC wire image could occur that would break
the multiplexing scheme in the future so the document currently only applies to
QUICv1.
The changes made between -02 and -01 included clarification of multiplexing
scenarios. One scenario is where P2P QUIC is used only for data exchange, with
SRTP/SRTCP used for media with DTLS-SRTP key management. This scenario would
not require modification of QUIC congestion control algorithms, but requires
multiplexing of QUIC with SRTP/SRTCP, STUN, TURN and DTLS. The second scenario
is RTP over QUIC. This scenario requires multiplexing of QUIC with STUN/TURN
only.
The other change relates to references. The normative dependencies of the
document have now been published as RFCs, including RFC 8489 (STUN), RFC 8656
(TURN), RFC 9000 (QUIC transport) and RFC 9001 (QUIC-TLS).
What are the next steps?
Magnus: Is the document compatible with QUICv2?
Bernard: The document currently doesn't require that QUICv2 be compatible, so
I'm not sure whether it is or not. Is QUICv2 mature enough for analysis?
Magnus: QUICv2 is stable enough for analysis. It will be done in a year or
faster and it is supposed to be completely backward compatible except for greasing.
Colin: As I understand it, the greasing should not affect QUIC multiplexing.
10:58
Jonathan: Another possibility (referring to the chat) is “if you muxing, don’t negotiate
greasing”
Cullen: My opinion is that multiplexing is important enough that the
QUIC WG should agree not to break this in QUICv2.
Bernard: I agree, but it wasn't easy to get a commitment to make it work in QUICv1.
Colin: I would be surprised if the QUIC WG goes along with an iron-clad commitment to
multiplexing for future versions. Better to say "this works for v1, and no
guarantees for the future".
Jonathan: Next step: informative reference to QUICv2, analysis of compatibility, then WGLC
5. SDP for RTP over QUIC (S. Dawkins, 15 min)
https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic
11:02 presentation
Slide 40
11:10
Colin: With respect to double encryption: unconvinced it makes sense to run RTP
over QUIC at all. Many parts of RTP do not fit well into QUIC (many examples).
But you could reuse payload formats over QUIC.
Bernard: Agree that payload format reuse is valuable. Aspects of RTP/RTCP may
turn out to be useful. RTP over QUIC effort is trying to figure that out.
It is possible to experiment with alternative media transport now, using
WebCodecs for encode/decode and WebRTC data channel or WebTransport for
transport. RTCDataChannel is widely used to transport containerized media
today, which can be decoded/rendered via the MSE API. We are now seeing a move
from MSE to WebCodecs and along with that, a move from containerized transport
(required by MSE) to non-containerized (required by WebCodecs), where DRM is
not needed. In transporting frames over RTCDataChannel or QUIC, developers
often end up using RTP-like formats.
Magnus: SRTP makes sense for middleboxes
Cullen: resonate with Colin, but we do RTP over QUIC now. Double encryption
may be needed Stephan: create doc throwing away all the stuff we don’t need
from legacy RTP.
11:20
James Guessing: also review interesting RTP payload
formats to see what makes sense over QUIC and what not Stephan: maybe put
things into Joergs draft.
Bernard: Most of the low-latency streaming services I
see today are using reliable/unordered or reliable/ordered transport, not
unreliable/unordered (e.g. QUIC datagrams). Packet formats often similar
to RTP, with a seqquence number (for re-ordering and loss), a timestamp,
a payload-type field to differentiate codecs and an SSRC-like field to
differentiate streams. To deal with loss, you need to reset encoder state
(FIR) or respond to a lost picture (PLI).
Developers stuff an I-frame into a single message and then see datagrams
with high jitter. This isn't a transport problem - it can be solved with
packetization. WebTransport API spec talks about datagram priority, but if
I-frames are transported in huge messages on reliable streams, QUIC datagrams
get stuck waiting for them to be transmitted, and show high jitter.
So applications don't need to wait for priority to fix this, they can
implement packetization and interleaving of audio/video.
6. Game Moves over RTP (C. Jennings, 15 min)
https://datatracker.ietf.org/doc/html/draft-jennings-dispatch-game-state-over-rtp
11:27 presentation
Cullen Jennings: Online real time gaming needs to synchronize player and game
object state with low latency and synchronization with other media. Microsoft
Mixed Reality Toolkit (MRTK) is an example. It is an open source SDK, widely
used not just with Hololens, which encodes hand joint locations and the rate of
change in RTP. This allows the receiver to render a smooth hand motion. The
draft proposes to use RTP to provide support for current state and rate of
change. Lots of things don't want RTP but lots do. It provides extensible
structured data with TLVs (tag, length, value) that could be used by any
application. Applications can easily get a code point for their schema. Draft
needs: lots more RTP crank wheel template stuff, plus broader input on base
types and objects. There is an open source implementation:
https://github.com/cisco/gse
If IETF is the wrong place to do this let us know now!
Is this in scope for AVTCore?
Could we move forward with base draft and non controversial objects (move
controversial object to extension drafts )
Stephan: Should this go to MPEG haptics or someplace, as this is a codec.
Cullen: considering that.
Suhas: May be in scope of AVTcore
Sergio: Sending data in RTP doesn't work well with WebRTC since removal of the
RTP data channel. Could we use the SCTP data channel instead? It could work
like the T.140 gateway handles Realtime Text.
Stephan: @Sergio: unsynchronized does not work for multiplayer/fairness.
Cullen: Transporting this kind of info over the SCTP data channel has issues.
Bernard: RTP is appealing because it provides timing information which can be
forwarded by an SFU along with the media. Data channel is harder to integrate;
you either need to put a gateway in front of the SFU (like the T.140 gateway)
or you need to customize the SFU to forward the data chnanel info to
participants in the conference. So why not define the native RTP payload format?
Mo: Agreed. This is simple/generic enough for fast-track
standardization.
Bernard: Why not give it a try in AVTCORE? If you can contact
interested parties, it could work. Even if they don't want to do it in IETF, if
there is a community of interest, they can tell you what forum might be better.
Mo: Let's try to avoid having simple things mushroom. We're not trying to
tackle the entire metaverse problem here. The problem is too small for a new WG.
Magnus: format question should go to dispatch.
Cullen: We took it to Dispatch. They weren't responsive.
I don't want to play "find a rock". For this effort, failure is an
option. The document isn't a threat to the architecture of the Internet.
If it fails to gain traction, no harm will be done. It'll just be
another Internet draft that didn't get widely implemented.
Colin: Why is this controversial? Just do it!
Bernard: Let's do a Call for Adoption, have it go a bit longer than usual,
so it can be forwarded to people who might be interested. Maybe you'll
be able to form a community of interest, or at least get feedback or suggestions
for an alternative venue.
Next step: Issue a Call for adoption.
6. Short Tags (Cullen)
Cullen: I have some ideas on how to progress on the short tags problem that
Harald raised at the AVTCORE virtual interim in February. But there isn't much
time to get into it here, so we'll take it to the mailing list.
Magnus: A while ago I helped John Mattsson to write a paper that analyzed how a
known weakness in AES-GCM was impacted by RTP. NIST’s recommendation at that time
did miss an assumption that does not hold when using RTP/RTCP. With RTP/RTCP a
falsification attempt can in some cases be detected externally, and that allows
one to potentially break the integrity key. Paper is here:
https://eprint.iacr.org/2015/477.pdf
7. Wrapup and Next Steps (Chairs, 10 min)
Not enough time left to go over all the action items.
Bernard and Jonathan will go over the minutes and update the Action Item list.
