[{"author": "Jonathan Lennox", "text": "I plan to be at IETF in person
", "time": "2022-05-19T17:02:01Z"}, {"author": "Mathis Engelbart", "text": "I plan to be there in person
", "time": "2022-05-19T17:02:27Z"}, {"author": "spencerdawkins", "text": "I'm likely to be in person at IETF 114
", "time": "2022-05-19T17:02:38Z"}, {"author": "Mo Zanaty", "text": "+1 in person
", "time": "2022-05-19T17:02:46Z"}, {"author": "spencerdawkins", "text": "Oh, no. Still CoViD-19 ...
", "time": "2022-05-19T17:03:24Z"}, {"author": "Stephan Wenger", "text": "likely there in person
", "time": "2022-05-19T17:03:26Z"}, {"author": "Jonathan Lennox", "text": "I am getting the phenomenon where I can't hear unless my audio is enabled, it seems. So I'm leaving my mic on.
", "time": "2022-05-19T17:06:42Z"}, {"author": "Roman Shpount", "text": "I'm likely will be there in person
", "time": "2022-05-19T17:08:36Z"}, {"author": "Joerg Ott", "text": "Likely in person
", "time": "2022-05-19T17:33:41Z"}, {"author": "Joerg Ott", "text": "Mathis first
", "time": "2022-05-19T17:59:37Z"}, {"author": "Stefan Holmer", "text": "+1 to what Sergio says. Also random (non-congestion induced) loss
", "time": "2022-05-19T18:03:05Z"}, {"author": "Joerg Ott", "text": "Guess what we have done ;we re-ran all experiments
", "time": "2022-05-19T18:05:31Z"}, {"author": "Joerg Ott", "text": "Yes to Jonathan
", "time": "2022-05-19T18:08:11Z"}, {"author": "Joerg Ott", "text": "Well, whatever you would decide to be your sensible ADU (you could split a frame voluntarily)
", "time": "2022-05-19T18:08:43Z"}, {"author": "Sergio Garcia Murillo", "text": "what is the benefit of using a quic stream vs a quic datagram?
", "time": "2022-05-19T18:09:12Z"}, {"author": "Jonathan Lennox", "text": "Transport-level reliability, and avoiding having to do reassembly at the RTP layer, I'd guess?
", "time": "2022-05-19T18:09:57Z"}, {"author": "Joerg Ott", "text": "QUIC stream doesn't require the datagram extension
", "time": "2022-05-19T18:09:59Z"}, {"author": "Joerg Ott", "text": "Transport layer reliability (+ many folks did exactly this in the past)
", "time": "2022-05-19T18:10:13Z"}, {"author": "Joerg Ott", "text": "And this was brought up during the last meeting as something to document
", "time": "2022-05-19T18:10:41Z"}, {"author": "Sergio Garcia Murillo", "text": "but basically you are preventing any RTP over QUIC stream interorability with DTLS/SRTP (i am thinking in a mixed SFU model)
", "time": "2022-05-19T18:10:46Z"}, {"author": "Joerg Ott", "text": "There are many different use cases; not all protocols combinations will fit all purposes
", "time": "2022-05-19T18:11:12Z"}, {"author": "Joerg Ott", "text": "This is negotiable in the end
", "time": "2022-05-19T18:11:36Z"}, {"author": "Joerg Ott", "text": "(e.g., in SDP)
", "time": "2022-05-19T18:12:14Z"}, {"author": "Joerg Ott", "text": "@Sergio: Understand the mixed MCU model (RTP topologies will likely raise even more fundamental issues)
", "time": "2022-05-19T18:13:36Z"}, {"author": "Joerg Ott", "text": "We haven't looked into ICE signalling yet
", "time": "2022-05-19T18:18:24Z"}, {"author": "Jonathan Lennox", "text": "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.
", "time": "2022-05-19T18:20:04Z"}, {"author": "Sergio Garcia Murillo", "text": "yes, my question is how setting up ICE outside QUIC interacts with the flow identifier
", "time": "2022-05-19T18:20:44Z"}, {"author": "Joerg Ott", "text": "right
", "time": "2022-05-19T18:20:47Z"}, {"author": "Joerg Ott", "text": "This is an open question at this point
", "time": "2022-05-19T18:21:04Z"}, {"author": "Sergio Garcia Murillo", "text": "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
", "time": "2022-05-19T18:23:07Z"}, {"author": "Joerg Ott", "text": "It's different RTP sessions (if they contain RTP)
", "time": "2022-05-19T18:24:53Z"}, {"author": "Joerg Ott", "text": "effectively a replacement for port-based multiplexing
", "time": "2022-05-19T18:25:35Z"}, {"author": "Sergio Garcia Murillo", "text": "rtp session as defined in https://datatracker.ietf.org/doc/html/rfc7656#page-14
", "time": "2022-05-19T18:25:52Z"}, {"author": "Sergio Garcia Murillo", "text": "?
", "time": "2022-05-19T18:25:53Z"}, {"author": "Joerg Ott", "text": "(how to fold this into ICE may be a bit more tricky)
", "time": "2022-05-19T18:25:56Z"}, {"author": "Joerg Ott", "text": "According to section 3 of RFC3550
", "time": "2022-05-19T18:27:19Z"}, {"author": "Roman Shpount", "text": "yes, you can do bandwidth control in the browser
", "time": "2022-05-19T18:31:03Z"}, {"author": "spencerdawkins", "text": "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 ...
", "time": "2022-05-19T18:39:16Z"}, {"author": "Jonathan Lennox", "text": "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.
", "time": "2022-05-19T18:43:05Z"}, {"author": "Stefan Holmer", "text": "agree, jonathan
", "time": "2022-05-19T18:45:31Z"}, {"author": "Jonathan Lennox", "text": "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.
", "time": "2022-05-19T18:46:46Z"}, {"author": "Stefan Holmer", "text": "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
", "time": "2022-05-19T18:46:51Z"}, {"author": "Sergio Garcia Murillo", "text": "i kind of agree, but I also think that taking account application delay is interesting in order to reduce the end to end delay
", "time": "2022-05-19T18:46:55Z"}, {"author": "Shuai Zhao", "text": "@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?
", "time": "2022-05-19T18:47:11Z"}, {"author": "Roman Shpount", "text": "It should be UDP/QUIC/RTP/AVPF
", "time": "2022-05-19T18:47:28Z"}, {"author": "Sergio Garcia Murillo", "text": "+1 to UDP/QUIC/RTP/AVPF
", "time": "2022-05-19T18:47:56Z"}, {"author": "Jonathan Lennox", "text": "Shuai: That was the consensus as I understood it, yes.
", "time": "2022-05-19T18:47:58Z"}, {"author": "Stefan Holmer", "text": "@sergio, yes, but i wouldn't necessarily want the cc algorithm to deal with that.
", "time": "2022-05-19T18:48:00Z"}, {"author": "Stefan Holmer", "text": "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
", "time": "2022-05-19T18:48:59Z"}, {"author": "Sergio Garcia Murillo", "text": "@stefan not really sure, would love to experiment the behaviour of browser vs js app feedback, maybe we are complicating the browser implementation unnecesarily
", "time": "2022-05-19T18:49:37Z"}, {"author": "Sergio Garcia Murillo", "text": "but yes, if the timestamps are available in quic feedback, let's reuse them
", "time": "2022-05-19T18:50:07Z"}, {"author": "Joerg Ott", "text": "thanks much, Spencer
", "time": "2022-05-19T18:50:26Z"}, {"author": "Jonathan Lennox", "text": "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?
", "time": "2022-05-19T18:51:24Z"}, {"author": "Sergio Garcia Murillo", "text": "but then what is the difference of a flow id and a mid?
", "time": "2022-05-19T18:51:57Z"}, {"author": "Sergio Garcia Murillo", "text": "seems redundant
", "time": "2022-05-19T18:52:06Z"}, {"author": "Jonathan Lennox", "text": "This is basically another grouping layer at a level above BUNDLE.
", "time": "2022-05-19T18:52:10Z"}, {"author": "Roman Shpount", "text": "Why would it be needed?
", "time": "2022-05-19T18:52:27Z"}, {"author": "Jonathan Lennox", "text": "For BUNDLE (Unified) mid is an RTP stream, this is an RTP session.
", "time": "2022-05-19T18:52:29Z"}, {"author": "Jonathan Lennox", "text": "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?
", "time": "2022-05-19T18:53:01Z"}, {"author": "Jonathan Lennox", "text": "(Correction, mid isn't an RTP stream, it's more complicated than that, but it's smaller than a session.)
", "time": "2022-05-19T18:53:40Z"}, {"author": "Roman Shpount", "text": "The question is if we need multiple RTP sessions over the same QUIC connection
", "time": "2022-05-19T18:53:55Z"}, {"author": "Joerg Ott", "text": "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
", "time": "2022-05-19T18:54:25Z"}, {"author": "Jonathan Lennox", "text": "I don't know if we need it; J\u00f6rg mentioned it as a possibility.
", "time": "2022-05-19T18:54:38Z"}, {"author": "Joerg Ott", "text": "One point of many discussions was saving port numbers. We do all kinds of multiplexing
", "time": "2022-05-19T18:54:54Z"}, {"author": "Joerg Ott", "text": "QUIC gives us an opportunity to do this (what we did before over UDP). So why lose this property?
", "time": "2022-05-19T18:55:14Z"}, {"author": "Jonathan Lennox", "text": "It seems kind of redundant with BUNDLE, though there are cases where BUNDLE isn't applicable or desirable.
", "time": "2022-05-19T18:55:41Z"}, {"author": "Jonathan Lennox", "text": "But if we do do it, we need to figure out what it looks like in SDP.
", "time": "2022-05-19T18:56:18Z"}, {"author": "Roman Shpount", "text": "I see. I think WebRTC without bundle does not get a lot of use
", "time": "2022-05-19T18:56:30Z"}, {"author": "Joerg Ott", "text": "The main problem we thought of that you may not just have RTP sessions. But this needs careful considerations
", "time": "2022-05-19T18:56:33Z"}, {"author": "Mathis Engelbart", "text": "@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.
", "time": "2022-05-19T18:56:41Z"}, {"author": "Roman Shpount", "text": "We definitely need RTP and non-RTP at least as data channel replacement
", "time": "2022-05-19T18:57:20Z"}]