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

GMT+0
[16:04:37] <zulipbot> (Roni Even) I am on my phone
[16:09:59] <zulipbot> (Stephan Wenger) I'm juggling two calls.  If you have anything specific for me and I don't respond, please put it in the chat.
[16:11:01] <zulipbot> (Jonathan Lennox) Stephan, can you update the EVC draft?
[16:11:33] <zulipbot> (Stephan Wenger) I have no audio right now.
[16:11:46] <zulipbot> (Lauri Ilola) Seems you cant hear me
[16:11:46] <zulipbot> (Lauri Ilola) https://datatracker.ietf.org/submit/status/130061/
[16:11:59] <zulipbot> (Stephan Wenger) EVC draft will be revved as soon as RFC 9324 is published; any day now.  Mid Jan the latest, probably earlier
[16:12:17] <zulipbot> (Stephan Wenger) I get audio: 0 kbps.  Anyone else?
[16:14:20] <zulipbot> (Nils Ohlmeier) I'm getting 10-20 kbps audio
[16:16:38] <zulipbot> (Stephan Wenger) Had to reboot my Mac.  And I thought rebooting helps only with Windows PCs?????
[16:17:22] <zulipbot> (Youenn Fablet) @Stephan, if you are using Safari, feel free to file a bug in bugs.webkit.org and send me a sysdiagnose (youenn@apple.com)
[16:18:52] <zulipbot> (Stephan Wenger) Green Metadata is Leonardo's sin, but it's known now
[16:32:50] <zulipbot> (Rui Paulo) max_streams is not about open streams
[16:33:26] <zulipbot> (Joerg Ott) No
[16:33:39] <zulipbot> (Rui Paulo) rfc9000 "A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection. "
[16:35:58] <zulipbot> (Jan-Ivar Bruaroey) To clarify: the await/then issue isn't about a technical difference, but about whether the JS sender blocks writing more bytes on the successful queuing of bytes it just wrote. pipeTo() backpressure uses await writer.ready for this reason which resolves ahead of writer.write(), for better concurrency
[16:37:26] <zulipbot> (Vidhi Goel) Though max_streams is cumulative, quic implementation increases that limit anytime streams are closed. So, it tries to maintain some number of streams always open
[16:39:19] <zulipbot> (Joerg Ott) MVP
[16:39:32] <zulipbot> (Joerg Ott) MVP
[16:39:45] <zulipbot> (Mo Zanaty) @Vidhi, any spec ref to justify such implementation? It sounds wrong from a brief scan of RFC 9000.
[16:40:55] <zulipbot> (Joerg Ott) @Mo: It is treated as a sliding window according to some discussions on the moq list, IIRC
[16:46:12] <zulipbot> (Stephan Wenger) can we PLEASE use zoom for future calls
[16:50:09] <zulipbot> (Shuai Zhao) I don’t think Stephan has audios
[16:50:22] <zulipbot> (Stephan Wenger) I'm going to shoot this computer!
[16:50:22] <zulipbot> (Dale Worley) Stephan:  Nobody can hear you.
[16:50:36] <zulipbot> (Stephan Wenger) +1 to Peter's pont.  ALso, the slide is overly standards-centric.  Define applications not be call control etc. standards.
[16:51:05] <zulipbot> (Stephan Wenger) I still want a drop-in replacement for RTP over UDP without standardized call controls, as this is what large segments of the industry are using
[16:51:33] <zulipbot> (Stephan Wenger) can we PLEASE PLEASE PLEASE use zoom henceforth
[16:52:57] <zulipbot> (Stephan Wenger) Trying to clear my queue
[17:00:12] <zulipbot> (Joerg Ott) QUIC TS could be used as an improvement if available but certainly would not be mandated
[17:01:04] <zulipbot> (Joerg Ott) At the last IETF, Christian Huitema was trying to see how much interest there was in QUIC TS
[17:01:17] <zulipbot> (Rui Paulo) would quic timestamps interact with rtp's timestamps ?
[17:01:17] <zulipbot> (Joerg Ott) within the QWUIC WG
[17:01:30] <zulipbot> (Joerg Ott) there was limited response at this point
[17:01:58] <zulipbot> (Rui Paulo) @joerg, that may have been because of an application, but it seems like RTP could be a motivating factor
[17:03:54] <zulipbot> (Rui Paulo) we don't hear any echo, btw.
[17:05:28] <zulipbot> (Joerg Ott) lucky you, at least then I was intelligible
[17:14:19] <zulipbot> (Harald Alvestrand) Is QUIC over TCP even defined?
[17:15:02] <zulipbot> (Rui Paulo) I hope not :-)
[17:17:46] <zulipbot> (Harald Alvestrand) So QUIC over TCP is QUIC over UDP over MASQUE? Stack ALL the layers!
[17:20:08] <zulipbot> (Sam Hurst) HTTP/3 doesn't specify the congestion control, the QUIC transport layer does?
[17:22:02] <zulipbot> (Rui Paulo) @Sam, that is correct.
[17:25:10] <zulipbot> (Vidhi Goel) The examples of NADA and Scream shouldn’t be taken as the only options
[17:30:51] <zulipbot> (Sam Hurst) Is this multiplexing question more of a general topic, and possibly not unique to running RTP over QUIC? Maybe it's more generally useful to define some transport extension which specifies a generic stream type like that defined by H3 for unidirectional stream types?
[17:32:35] <zulipbot> (Sergio Garcia Murillo) what's the use case of multiplexing multiple RTP sessions over the same QUIC connection?
[17:39:03] <zulipbot> (Jan-Ivar Bruaroey) but allowPooling defaults to false?
[17:39:44] <zulipbot> (Jan-Ivar Bruaroey) So if I create two new WebTransport(url); in the same document, they fail? Not sure that is correct
[17:39:57] <zulipbot> (Jan-Ivar Bruaroey) also iframes
[17:44:43] <zulipbot> (Jan-Ivar Bruaroey) A WebTransport session is a session of WebTransport over HTTP/3. There may be multiple WebTransport sessions on one connection, when pooling is enabled.
[17:45:53] <zulipbot> (Vidhi Goel) I would argue against over webtransport or http as there are applications that don’t do either.
[17:47:23] <zulipbot> (Vidhi Goel) If you want to just take the multiplexing logic from webtransport, then I think it needs to very clear
[17:48:03] <zulipbot> (Jonathan Lennox) Bernard, I think you've lost audio
[17:49:56] <zulipbot> (Mo Zanaty) Are we ending in 10 min at 10am PST?
[17:59:54] <zulipbot> (Spencer Dawkins) Mo, I heard a chair say maybe we can run over a bit ...
[18:01:09] <zulipbot> (Mo Zanaty) Spencer, I have a conflicting meeting starting now, so thanks for taking over the minutes.
[18:11:19] <zulipbot> (Harald Alvestrand) need to go!