Audio/Video Transport Core Maintenance (avtcore) Working Group CHAIRS: Jonathan Lennox Bernard Aboba Virtual Interim Agenda Thursday, May 19, 2022 10 AM - noon Pacific Time 17:00 - 19:00 UTC Meeting link: https://meetings.conf.meetecho.com/interim/?short=144e158a-fc0a-4d67-855c-0f50babca848 Slides: https://docs.google.com/presentation/d/1ot8QMaR6lRSz4ULcJlXkqQHkyKlzsV382447s962QeA/
Preliminaries (Chairs, 10 min) Note Well, Note Takers, Agenda Bashing, Draft status, IPR declarations IETF 114 will be a hybrid meeting. Who will be there in person? Possible: Mathis Engelbart, Spencer Dawkins, Mo Zanaty, Stephan Wenger, Roman Shpount, Joerg Ott Bernard: An IPR declaration has been received relating to cryptex. Is there any objection to proceeding with the document due to this? No objections raised. Cryptex (Sergio Garcia Murillo, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-cryptex https://github.com/juberti/cryptex/issues Sergio: On GENART review are there are any preferences on the Section 4 proposed changes? Bernard: The choices look very similar. Sergio: I have a slight preference for the secdond choice. Sergio: ARTART Review (Section 5.2 Receiving). Issue is with "The implementation SHOULD stop and report an error if it considers use of this specification mandatory for the RTP stream" Bernard: SDP reflects the ability of the Offerer and Answerer to receive cryptex. The policy in the API is "negotiate" (send without cryptex if the other peer doesn't support receiving it) or "require" (fail the negotiation if the other side doesn't support receiving cryptex). Is this a situation where both sides indicated support for cryptex, yet cryptex isn't being received? Or are we talking about cryptex not being negotiated in a situation where a peer requires it? Sergio: will double check. Frame Marking RTP Header Extension (Mo Zanaty, 5 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking Mo: The IESG seems to be changing their view of Experimental status. Is WG still thinking this is experimental? Jonathan: maybe informational? check IESG? Bernard: There are multiple forwarding RTP header extensions in use today: framemarking, Generical Framemarking Descriptor, Dependency Descriptor, all implemented in the Chromium code base at some point. Mo: Framemarking header extensions are "experimental" in the general sense. Stephan: not recommended for informative with current text Mo: propose new text and see if people like it. RTP Payload for SCIP (Daniel Hanson, 10 minutes) https://datatracker.ietf.org/doc/html/draft-hanson-avtcore-rtp-scip Bernard: The term "end-to-end" is used differently in SCIP than in SFRame. Here the conferencing server is considered a trusted endpoint? Daniel: Yes. Bernard: When you say that things like bundle, RTP/RTCP multiplexing, feedback are "beyond the scope of SCIP" are you saying that these things could be negotiated (e.g. not prohibited)? Daniel: The existing specifications can be reused. A SCIP implementation could negotiate them (or not). Mike: what is next step? Bernard: reviewer feedback (SDP Directorate, ARTART, SECDIR, etc.), then request for IESG publication Mike: will upload revision with changes. Bernard: After that is uploaded, we will initiate directorate reviews. RFC7983bis (B. Aboba, 10 min) https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis Bernard: ready for WGLC? any concerns? Jonathan: ready for last call. Bernard: any concern with QUIC grease? Jonathan: ask QUIC WG if there is knob to turn if off Bernard: It is negotiated as a transport parameter, but typically no knob in QUIC APIs to influence that. Mo: its fine for last call. I suspect that QUIC bit greasing will fail to be deployed widely. QUIC congestion control for RTP (D. Baldassin, 10 min) https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic David: The results presented with respect to SCReaM under New Reno were influenced by a bug in SCReaM. Reran the tests after fixing the bug, now results of SCReaM under New Reno and SCReaM are very similar, indicating sending rate is application-limited. Spencer: thank you for reporting these results. did you document the environment that you were using anywhere? David: not really. We used the same setup as in https://www.in.tum.de/fileadmin/w00bws/cm/papers/epiq21-rtp-over-quic.pdf Spencer: I look forward to your results from the next experiment you described in your slides. Jonathan: We always thought running SCReAM over NewReno would be terrible, but your results are saying NewReno is application-limited and doesn't really have an effect? David: right Bernard: remember that this was a single-stream experiment. Simulcast, for instance, might be different, because it implies multiplicative increase, not additive increase. RTP over QUIC (J. Ott, M. Engelbart, 15 min) https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic Mathis: We are using a flow identifier (described in draft-ietf-masque-h3-datagram) to differentiate RTP sessions. New draft supports RTP both over QUIC datagrams and reliable streams. Note: Context ID of earlier h3-datagram drafts has been removed. Only Quarter Stream ID left in current draft. Review by MASQUE WG? Sergio: how do you map RTP onto a QUIC reliable stream? Mathis: one ADU per RTP packet (separate stream for each ADU). No RFC 4571 length field. Srinivas: regarding how RTCP timestamp. Mathis: map RTCP packet for CC feedback and RTCP timestamp won't be discarded. Spencer: On slide 47, is "exporting statistics" to the application Mathis: Yes, it's what QUIC exposes to App Bernard: will do WG adoption after next revision Joerg: can we do WG adoption without security section? Spencer: I'd encourage the chairs to call for WG adoption earlier. People (including me and the nice people at W3C Web Transport WG) are treating this draft as a baseline, but AVTCORE hasn't adopted it yet - relying on an individual draft isn't a good plan. This draft is in sufficiently good shape for WG to work on it. Suggest WG to adopt earlier rather than later. Jonathan: do you say personally you think WG should adopt it? Spencer: absolutely. Jonathan: will discuss with Bernard and come back WebTransport Liaison (Will Law, 15 min) Will Law: The WebTransport API is a Javascript API for use by applications running in browsers. In a browser, an application cannot have tight integration with the QUIC stack. For example, we have WHATWG Streams send/receive queues (which should be short) as well as QUIC send/receive queues, typically operating in another process for security reasons. Will Law: WebTransport API does not provide low level access to some of the information that has been indicated as useful for congestion control. We have added stats such as smoothedRtt, minRtt, rttVariation. But we do not have latest_rtt, ecn or ACK info, or pkt_departure/pkt_arrival time. Mathis: Maybe do experimental and see what parameters are needed. Will: what will be the necessary info via the browers to the JS application? Mathis: not sure if RTT measurements are necessary at this moment. Roman: get aggregated packet arrival or average in a given period, actual or inter-packet arrival may be a ideal approach Mo: broswer QUIC stack will have some sort of congestion control already, but it may fight with application congestion control. So the application needs to obtain stats on the underlying cc in the browwer. JS might need to work around this. Will: are there candidate CC for JS app? Bernard: The RMCAT WG defined several algorithms which were published as Experimental RFCs, plus there is a draft on Google Congestion Control. Stefan: First, it is important to understand the role of QUIC cc in a web browers. I have personally tried NewReno as a QUIC CC algorithm for an RTC application and it works reasonaly well. But adding the missing packet departure and arrival info would be useful, at least for Google Congestion Control (gcc). Sergio: it is still a good idea to have low level cc for browser JS app. I don't think you can ship "circuit breaker" CC in a browser QUIC implementation. SDP for RTP over QUIC (S. Dawkins, 10 min) https://datatracker.ietf.org/doc/html/draft-dawkins-sdp-rtp-quic Spencer: working on draft-dawkins-sdp-rtp-quic, tracking draft-engelbart-rtp-over-quic (which I'd love to see adopted) Keeping broader issues in separate GitHub repo (https://github.com/SpencerDawkins/sdp-rtp-quic-issues) Proposing three resolutions - looking forward to input from working group in the Github repo and mailing list. What AVP profiles to register - Issue 5 https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/5 Streams, Datagrams, or both? - Issue 8 https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/8 and Issue 3 https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/3 Signaling media-friendly congestion control? Issue 1 - https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/1 No time for Q&A RTP Payload for V3C (Lauri Ilola, 10 min) https://datatracker.ietf.org/doc/html/draft-ilola-avtcore-rtp-v3c Lauri:Looking for additional authors/contributors? Shuai:what is the status in 3GPP? Srinivas: video swg. still under discussion. Wrapup and Next Steps (Chairs, 10 min) ----------------- Jabber conversation history below: Jonathan Lennox I plan to be at IETF in person10:04:58 Mathis Engelbart I plan to be there in person10:05:24 spencerdawkins I'm likely to be in person at IETF 11410:05:35 Mo Zanaty +1 in person10:05:43 spencerdawkins Oh, no. Still CoViD-19 ...10:06:21 Stephan Wenger likely there in person10:06:23 Jonathan Lennox I am getting the phenomenon where I can't hear unless my audio is enabled, it seems. So I'm leaving my mic on.10:09:39 Roman Shpount I'm likely will be there in person10:11:33 Joerg Ott Likely in person10:36:38 Mathis first11:02:34 Stefan Holmer +1 to what Sergio says. Also random (non-congestion induced) loss11:06:02 Joerg Ott Guess what we have done ;we re-ran all experiments11:08:28 Yes to Jonathan11:11:08 Well, whatever you would decide to be your sensible ADU (you could split a frame voluntarily)11:11:40 Sergio Garcia Murillo what is the benefit of using a quic stream vs a quic datagram?11:12:09 Jonathan Lennox Transport-level reliability, and avoiding having to do reassembly at the RTP layer, I'd guess?11:12:54 Joerg Ott QUIC stream doesn't require the datagram extension11:12:57 Transport layer reliability (+ many folks did exactly this in the past)11:13:11 And this was brought up during the last meeting as something to document11:13:38 Sergio Garcia Murillo but basically you are preventing any RTP over QUIC stream interorability with DTLS/SRTP (i am thinking in a mixed SFU model)11:13:44 Joerg Ott There are many different use cases; not all protocols combinations will fit all purposes11:14:09 This is negotiable in the end11:14:34 (e.g., in SDP)11:15:12 @Sergio: Understand the mixed MCU model (RTP topologies will likely raise even more fundamental issues)11:16:34 We haven't looked into ICE signalling yet11:21:21 Jonathan Lennox I don't think ICE inside QUIC makes very much sense...ICE outside QUIC is the scope of 7983bis discussed earlier but would also need additional signaling of some sort to get peer-to-peer QUIC working.11:23:01 Sergio Garcia Murillo yes, my question is how setting up ICE outside QUIC interacts with the flow identifier11:23:42 Joerg Ott right11:23:44 This is an open question at this point11:24:01 Sergio Garcia Murillo i think that at the end my question is what does each of the different flows defined by the flow-id means in terms of rtp terminology11:26:04 Joerg Ott It's different RTP sessions (if they contain RTP)11:27:50 effectively a replacement for port-based multiplexing11:28:32 Sergio Garcia Murillo rtp session as defined in https://datatracker.ietf.org/doc/html/rfc7656#page-1411:28:49 ?11:28:50 Joerg Ott (how to fold this into ICE may be a bit more tricky)11:28:53 According to section 3 of RFC355011:30:16 Roman Shpount yes, you can do bandwidth control in the browser11:34:00 spencerdawkins So, W3C Web Transport is looking at two levels of congestion controllers, (browser and not-browser), and the "not-browser" ALSO has two levels of congestion controllers itself? EXCELLENT ... 11:42:13 Jonathan Lennox I think having browser-based measurements of packet departure and arrival times are the important think for getting this to work in JS - you don't want to be measuring these timestamps in the browser, that'll be very vulnerable to application delays.11:46:02 Stefan Holmer agree, jonathan11:48:28 Jonathan Lennox There's a tradeoff between how much data the browser provides vs. the assumptions it makes about what the bwe algorithm needs. Raw packet departure and arrival times are the fewest assumptions but the most data. 11:49:44 Stefan Holmer and making sure there's a possibility of picking a browser-based cc algorithm that is unlikely to be limiting the cc in the app11:49:49 Sergio Garcia Murillo i kind of agree, but I also think that taking account application delay is interesting in order to reduce the end to end delay11:49:52 Shuai Zhao @Jonathan, for note purpose, the agreement for item 7: RTP over QUIC, is that WG will discuss the possibility of early WG adoption without new revision?11:50:08 Roman Shpount It should be UDP/QUIC/RTP/AVPF11:50:26 Sergio Garcia Murillo +1 to UDP/QUIC/RTP/AVPF11:50:53 Jonathan Lennox Shuai: That was the consensus as I understood it, yes.11:50:55 Stefan Holmer @sergio, yes, but i wouldn't necessarily want the cc algorithm to deal with that.11:50:57 what i do want to avoid is having to send the same timestamps twice, once in the quic protocol and once in the app layer11:51:56 Sergio Garcia Murillo @stefan not really sure, would love to experiment the behaviour of browser vs js app feedback, maybe we are complicating the browser implementation unnecesarily11:52:34 but yes, if the timestamps are available in quic feedback, let's reuse them11:53:04 Joerg Ott thanks much, Spencer11:53:23 Jonathan Lennox Another question for Spencer: if we're looking at different QUIC flow-ids are different RTP sessions, they'd presumably need to have separate media groups (m= lines) in SDP?11:54:21 Sergio Garcia Murillo but then what is the difference of a flow id and a mid?11:54:54 seems redundant11:55:03 Jonathan Lennox This is basically another grouping layer at a level above BUNDLE.11:55:07 Roman Shpount Why would it be needed?11:55:24 Jonathan Lennox For BUNDLE (Unified) mid is an RTP stream, this is an RTP session.11:55:26 Well, if it's a think that the protocol supports, presumably it should be signalable. If it's not needed, there's no need to put it in the protocl?11:55:58 (Correction, mid isn't an RTP stream, it's more complicated than that, but it's smaller than a session.)11:56:37 Roman Shpount The question is if we need multiple RTP sessions over the same QUIC connection11:56:52 Joerg Ott You should nevertheless be able to provide a mapping from RTP sessions/streams to flow-ids so a receiver knows what to expect where for demuxing11:57:22 Jonathan Lennox I don't know if we need it; Jörg mentioned it as a possibility.11:57:35 Joerg Ott One point of many discussions was saving port numbers. We do all kinds of multiplexing11:57:52 QUIC gives us an opportunity to do this (what we did before over UDP). So why lose this property?11:58:11 Jonathan Lennox It seems kind of redundant with BUNDLE, though there are cases where BUNDLE isn't applicable or desirable.11:58:38 But if we do do it, we need to figure out what it looks like in SDP.11:59:16 Roman Shpount I see. I think WebRTC without bundle does not get a lot of use11:59:28 Joerg Ott The main problem we thought of that you may not just have RTP sessions. But this needs careful considerations11:59:31 Mathis Engelbart @Roman I think the question also includes if we need RTP and non-RTP on the same connection. I think it might be useful to share the connection e.g. for shared congestion control, which would otherwise compete against each other.11:59:38 Roman Shpount We definitely need RTP and non-RTP at least as data channel replacement 12:00:17