IETF
avtcore@jabber.ietf.org
Thursday, May 19, 2022< ^ >
Jonathan Lennox has set the subject to: IETF AVTCore Working Group
Room Configuration
Room Occupants

GMT+0
[16:50:08] MikeFaller_web_497 joins the room
[16:50:08] Daniel Hanson_web_390 joins the room
[16:50:08] Bernard Aboba_web_969 joins the room
[16:50:08] Spencer Dawkins_web_466 joins the room
[16:50:08] Jonathan Lennox_web_806 joins the room
[16:50:18] Jonathan Lennox_web_806 leaves the room
[16:50:22] Jonathan Lennox_web_342 joins the room
[16:54:51] Stephan Wenger_web_621 joins the room
[16:55:23] Mo Zanaty_web_630 joins the room
[16:56:28] Spencer Dawkins_web_466 leaves the room
[16:56:32] Spencer Dawkins_web_714 joins the room
[16:57:16] Spencer Dawkins_web_714 leaves the room
[16:57:20] Spencer Dawkins_web_946 joins the room
[16:57:54] Sergio Garcia Murillo_web_857 joins the room
[16:58:30] Shuai Zhao_web_715 joins the room
[16:58:39] David Baldassin_web_711 joins the room
[16:59:09] Lukasz Kondrad_web_686 joins the room
[16:59:26] Lauri Ilola_web_560 joins the room
[17:00:01] Mathis Engelbart_web_744 joins the room
[17:00:14] Will Law_web_432 joins the room
[17:02:05] Stefan Holmer_web_923 joins the room
[17:02:24] Stefan Holmer_web_923 leaves the room
[17:02:28] Stefan Holmer_web_708 joins the room
[17:02:33] Srinivas Gudumasu_web_743 joins the room
[17:02:49] Ludovic Roux_web_493 joins the room
[17:04:30] spencerdawkins joins the room
[17:04:31] Shuai Zhao_web_715 leaves the room
[17:04:35] Shuai Zhao_web_510 joins the room
[17:04:58] <Jonathan Lennox_web_342> I plan to be at IETF in person
[17:05:24] <Mathis Engelbart_web_744> I plan to be there in person
[17:05:35] <spencerdawkins> I'm likely to be in person at IETF 114
[17:05:43] <Mo Zanaty_web_630> +1 in person
[17:06:21] <spencerdawkins> Oh, no. Still CoViD-19 ...
[17:06:23] <Stephan Wenger_web_621> likely there in person
[17:09:39] <Jonathan Lennox_web_342> I am getting the phenomenon where I can't hear unless my audio is enabled, it seems.  So I'm leaving my mic on.
[17:09:58] Roman Shpount_web_483 joins the room
[17:11:33] <Roman Shpount_web_483> I'm likely will be there in person
[17:13:31] Jonathan Lennox_web_342 leaves the room
[17:13:35] Jonathan Lennox_web_771 joins the room
[17:19:45] Harald Alvestrand_web_133 joins the room
[17:35:41] Joerg Ott_web_186 joins the room
[17:36:38] <Joerg Ott_web_186> Likely in person
[17:43:51] Roni Even_web_214 joins the room
[17:44:51] Ahmed Hamza_web_437 joins the room
[17:46:39] Roni Even_web_214 leaves the room
[17:46:43] Roni Even_web_276 joins the room
[17:52:21] Roni Even_web_276 leaves the room
[17:52:25] Roni Even_web_820 joins the room
[17:58:35] Roni Even_web_820 leaves the room
[17:58:39] Roni Even_web_563 joins the room
[17:59:23] MikeFaller_web_497 leaves the room
[17:59:27] MikeFaller_web_261 joins the room
[18:02:34] <Joerg Ott_web_186> Mathis first
[18:03:10] Roni Even_web_563 leaves the room
[18:06:02] <Stefan Holmer_web_708> +1 to what Sergio says. Also random (non-congestion induced) loss
[18:08:28] <Joerg Ott_web_186> Guess what we have done ;we re-ran all experiments
[18:08:35] Harald Alvestrand_web_133 leaves the room
[18:11:08] <Joerg Ott_web_186> Yes to Jonathan
[18:11:40] <Joerg Ott_web_186> Well, whatever you would decide to be your sensible ADU (you could split a frame voluntarily)
[18:12:09] <Sergio Garcia Murillo_web_857> what is the benefit of using a quic stream vs a quic datagram?
[18:12:54] <Jonathan Lennox_web_771> Transport-level reliability, and avoiding having to do reassembly at the RTP layer, I'd guess?
[18:12:56] <Joerg Ott_web_186> QUIC stream doesn't require the datagram extension
[18:13:10] <Joerg Ott_web_186> Transport layer reliability (+ many folks did exactly this in the past)
[18:13:38] <Joerg Ott_web_186> And this was brought up during the last meeting as something to document
[18:13:43] <Sergio Garcia Murillo_web_857> but basically you are preventing any RTP over QUIC stream interorability with DTLS/SRTP (i am thinking in a mixed SFU model)
[18:14:09] <Joerg Ott_web_186> There are many different use cases; not all protocols combinations will fit all purposes
[18:14:33] <Joerg Ott_web_186> This is negotiable in the end
[18:15:11] <Joerg Ott_web_186> (e.g., in SDP)
[18:16:33] <Joerg Ott_web_186> @Sergio: Understand the mixed MCU model (RTP topologies will likely raise even more fundamental issues)
[18:19:09] Stephan Wenger_web_621 leaves the room
[18:21:21] <Joerg Ott_web_186> We haven't looked into ICE signalling yet
[18:23:01] <Jonathan Lennox_web_771> 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.
[18:23:07] Stephan Wenger_web_618 joins the room
[18:23:41] <Sergio Garcia Murillo_web_857> yes, my question is how setting up ICE outside QUIC interacts with the flow identifier
[18:23:44] <Joerg Ott_web_186> right
[18:24:01] <Joerg Ott_web_186> This is an open question at this point
[18:26:04] <Sergio Garcia Murillo_web_857> 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 terminology
[18:27:50] <Joerg Ott_web_186> It's different RTP sessions (if they contain RTP)
[18:28:32] <Joerg Ott_web_186> effectively a replacement for port-based multiplexing
[18:28:49] <Sergio Garcia Murillo_web_857> rtp session as defined in  https://datatracker.ietf.org/doc/html/rfc7656#page-14
[18:28:50] <Sergio Garcia Murillo_web_857> ?
[18:28:53] <Joerg Ott_web_186> (how to fold this into ICE may be a bit more tricky)
[18:30:16] <Joerg Ott_web_186> According to section 3 of RFC3550
[18:34:00] <Roman Shpount_web_483> yes, you can do bandwidth control in the browser
[18:42:13] <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 ...
[18:46:02] <Jonathan Lennox_web_771> 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.
[18:48:28] <Stefan Holmer_web_708> agree, jonathan
[18:48:35] Ahmed Hamza_web_437 leaves the room
[18:48:39] Ahmed Hamza_web_519 joins the room
[18:49:40] Will Law_web_432 leaves the room
[18:49:43] <Jonathan Lennox_web_771> 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.  
[18:49:48] <Stefan Holmer_web_708> and making sure there's a possibility of picking a browser-based cc algorithm that is unlikely to be limiting the cc in the app
[18:49:52] <Sergio Garcia Murillo_web_857> i kind of agree, but I also think that taking account application delay is interesting in order to reduce the end to end delay
[18:50:08] <Shuai Zhao_web_510> @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?
[18:50:25] <Roman Shpount_web_483> It should be UDP/QUIC/RTP/AVPF
[18:50:53] <Sergio Garcia Murillo_web_857> +1 to UDP/QUIC/RTP/AVPF
[18:50:55] <Jonathan Lennox_web_771> Shuai: That was the consensus as I understood it, yes.
[18:50:57] <Stefan Holmer_web_708> @sergio, yes, but i wouldn't necessarily want the cc algorithm to deal with that.
[18:51:56] <Stefan Holmer_web_708> what i do want to avoid is having to send the same timestamps twice, once in the quic protocol and once in the app layer
[18:52:34] <Sergio Garcia Murillo_web_857> @stefan not really sure, would love to experiment the behaviour of browser vs js app feedback, maybe we are complicating the browser implementation unnecesarily
[18:53:04] <Sergio Garcia Murillo_web_857> but yes, if the timestamps are available in quic feedback, let's reuse them
[18:53:23] <Joerg Ott_web_186> thanks much, Spencer
[18:54:21] <Jonathan Lennox_web_771> 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?
[18:54:54] <Sergio Garcia Murillo_web_857> but then what is the difference of a flow id and a mid?
[18:55:03] <Sergio Garcia Murillo_web_857> seems redundant
[18:55:07] <Jonathan Lennox_web_771> This is basically another grouping layer at a level above BUNDLE.
[18:55:24] <Roman Shpount_web_483> Why would it be needed?
[18:55:26] <Jonathan Lennox_web_771> For BUNDLE (Unified) mid is an RTP stream, this is an RTP session.
[18:55:58] <Jonathan Lennox_web_771> 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?
[18:56:37] <Jonathan Lennox_web_771> (Correction, mid isn't an RTP stream, it's more complicated than that, but it's smaller than a session.)
[18:56:52] <Roman Shpount_web_483> The question is if we need multiple RTP sessions over the same QUIC connection
[18:57:22] <Joerg Ott_web_186> 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 demuxing
[18:57:35] <Jonathan Lennox_web_771> I don't know if we need it; Jörg mentioned it as a possibility.
[18:57:51] <Joerg Ott_web_186> One point of many discussions was saving port numbers. We do all kinds of multiplexing
[18:58:11] <Joerg Ott_web_186> QUIC gives us an opportunity to do this (what we did before over UDP). So why lose this property?
[18:58:38] <Jonathan Lennox_web_771> It seems kind of redundant with BUNDLE, though there are cases where BUNDLE isn't applicable or desirable.
[18:59:15] <Jonathan Lennox_web_771> But if we do do it, we need to figure out what it looks like in SDP.
[18:59:27] <Roman Shpount_web_483> I see. I think WebRTC without bundle does not get a lot of use
[18:59:30] <Joerg Ott_web_186> The main problem we thought of that you may not just have RTP sessions. But this needs careful considerations
[18:59:38] <Mathis Engelbart_web_744> @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.
[19:00:17] <Roman Shpount_web_483> We definitely need RTP and non-RTP at least as data channel replacement
[19:00:19] Stephan Wenger_web_618 leaves the room
[19:00:42] Daniel Hanson_web_390 leaves the room
[19:00:45] Roman Shpount_web_483 leaves the room
[19:00:51] MikeFaller_web_261 leaves the room
[19:00:52] David Baldassin_web_711 leaves the room
[19:00:52] Srinivas Gudumasu_web_743 leaves the room
[19:00:56] Ludovic Roux_web_493 leaves the room
[19:01:21] Jonathan Lennox_web_771 leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!