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. ![](https://notes.ietf.org/uploads/upload_ccb69266fbe5918b7b62e285367eebb8.png) 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. ![](https://notes.ietf.org/uploads/upload_058a72fec0e8c8e50e39e563033499c6.png) 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. ![](https://notes.ietf.org/uploads/upload_16947511949a3ca13a74de291c8d70b1.png) 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 ![](https://notes.ietf.org/uploads/upload_3ea8fd52298cdb01b8df056c7b4d316f.png) 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. ![](https://notes.ietf.org/uploads/upload_04ae914d448e76de7c7a8efa47f35d24.png) 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 ![](https://notes.ietf.org/uploads/upload_181327e93684cf5bd83f28d06f7bdc64.png) 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.