[{"author": "Cullen Jennings", "text": "I'm not seeing the right slide<br/>", "time": "2022-03-23T09:09:54Z"}, {"author": "Alan Frindell", "text": "which slide are you seeing?&nbsp;&nbsp;Not \"Summary of Use Cases\"<br/>", "time": "2022-03-23T09:10:18Z"}, {"author": "Craig Taylor", "text": "Same here (i think)<br/>", "time": "2022-03-23T09:10:20Z"}, {"author": "Cullen Jennings", "text": "oh, never mind - perhaps I am <br/>", "time": "2022-03-23T09:10:20Z"}, {"author": "Alan Frindell", "text": "Is it ok now?<br/>", "time": "2022-03-23T09:10:56Z"}, {"author": "Craig Taylor", "text": "yes<br/>", "time": "2022-03-23T09:11:06Z"}, {"author": "David Schinazi", "text": "For next time, please consider larger font sizes :-)<br/>", "time": "2022-03-23T09:12:52Z"}, {"author": "Barry Leiba", "text": "WDNNS large fonts!<br/>", "time": "2022-03-23T09:13:24Z"}, {"author": "Pete Resnick", "text": "Maybe the caffeine wore off at the wrong moment, but is there something about these use cases that are different than streaming that is currently going on?<br/>", "time": "2022-03-23T09:15:28Z"}, {"author": "Pete Resnick", "text": "OK.<br/>", "time": "2022-03-23T09:16:31Z"}, {"author": "Kirill Pugin", "text": "offline rendering/encoding/composition could be another use-case - it's kinda similar to Gaming or could be...<br/>", "time": "2022-03-23T09:16:41Z"}, {"author": "Murray Kucherawy", "text": "@Pete: Did you get an answer to that?<br/>", "time": "2022-03-23T09:17:06Z"}, {"author": "Pete Resnick", "text": "Yes, James and Mo answered at the mic.<br/>", "time": "2022-03-23T09:17:33Z"}, {"author": "Craig Taylor", "text": "Yes, fast switching is a distinct issue and big enough to call out<br/>", "time": "2022-03-23T09:17:51Z"}, {"author": "Pete Resnick", "text": "Short answer: No difference in the current stuff, but some of the later presentations will have some new use cases which are different.<br/>", "time": "2022-03-23T09:18:06Z"}, {"author": "Murray Kucherawy", "text": "Groovy, thanks.<br/>", "time": "2022-03-23T09:18:28Z"}, {"author": "lpardue", "text": "undead media<br/>", "time": "2022-03-23T09:18:34Z"}, {"author": "Murray Kucherawy", "text": "Undead, undead, undead.<br/>", "time": "2022-03-23T09:18:50Z"}, {"author": "Suhas Nandakumar", "text": "media is aLive<br/>", "time": "2022-03-23T09:19:12Z"}, {"author": "lpardue", "text": "ooh frankenmedia, I like it<br/>", "time": "2022-03-23T09:20:15Z"}, {"author": "Stefan Holmer", "text": "Is peer-to-peer distribution in scope? Imagining \"on-prem\" distribution of media to save bandwidth when a large number of viewers in the same local network want to consume the same content<br/>", "time": "2022-03-23T09:20:49Z"}, {"author": "Suhas Nandakumar", "text": "going back to Pete's question - agree that&nbsp;&nbsp;if we consider more modern use-cases like the one <a href=\"https://dashif.org/webRTC/report\" rel=\"nofollow\">https://dashif.org/webRTC/report</a> , where streaming and interactivity convergence, there is something more than today that might need us to thinking on to solve<br/>", "time": "2022-03-23T09:20:52Z"}, {"author": "Magnus Westerlund", "text": "Kirill I want you to think about your use case and see how it fit in after you seen the other presentation and if you see it still being relevant please bring it up in the discussion. <br/>", "time": "2022-03-23T09:21:35Z"}, {"author": "spencerdawkins", "text": "I SHOULD have also mentioned that the distinctions in the draft are mostly from James and from me, there's a github link in the draft, and we read new issues with gratitude ... <br/>", "time": "2022-03-23T09:22:04Z"}, {"author": "Victor Vasiliev", "text": "@Stefan well, the purpose of this meeting is to determine what things should be in scope; I've heard before from other folks they're interested in a similar scenario<br/>", "time": "2022-03-23T09:24:05Z"}, {"author": "Kirill Pugin", "text": "+1 to P2P<br/>", "time": "2022-03-23T09:24:25Z"}, {"author": "lpardue", "text": "think seriously about P2P given the fact that this is BoF is called media over QUIC and there is no standard P2P QUIC at this moment<br/>", "time": "2022-03-23T09:25:53Z"}, {"author": "Juliusz Chroboczek", "text": "Am I wrong in believing that WebRTC's adaptivity is an implementation choice, and in no way something that's intrinsic to the protocol suite?<br/>", "time": "2022-03-23T09:26:34Z"}, {"author": "Ali Begen", "text": "I corrected this in the google doc, but let me say it here because the slides still have the same error: LL-DASH does not have an extra manifest overhead. Please stop saying it does.<br/>", "time": "2022-03-23T09:26:56Z"}, {"author": "Pete Resnick", "text": "@Juliusz: +1. The reason I asked the earlier question is that I'm trying to get my head around why this is about QUIC in particular rather than just interesting new media cases. So for example, updating RTMP to support new codecs may be interesting, but doesn't seem to have anything to do with QUIC.<br/>", "time": "2022-03-23T09:26:56Z"}, {"author": "Varun Singh", "text": "Correct, WebRTC adaptivity is specific to the implementation<br/>", "time": "2022-03-23T09:27:22Z"}, {"author": "Suhas Nandakumar", "text": "@juliusz, that's my take on it. Its the configuration of the stack and webrtc has tools to pick one vs te other<br/>", "time": "2022-03-23T09:27:26Z"}, {"author": "Mo Zanaty", "text": "@Stefan, the quicr drafts explicitly consider the use case of optimizing local media distribution with CDN-like relays closer than the origin. An endpoint can also be a relay for P2P cases.<br/>", "time": "2022-03-23T09:27:33Z"}, {"author": "Cullen Jennings", "text": "@Juliusz - that is my view yes. Often when people say WebRTC, what they mean is \"what they can easily do from what is chome today\" <br/>", "time": "2022-03-23T09:27:35Z"}, {"author": "Kirill Pugin", "text": "LL-DASH has container overhead especially at low latency - 1 frame CMAF chunk<br/>", "time": "2022-03-23T09:27:36Z"}, {"author": "Jonathan Lennox", "text": "But if you want something you can run in the browser you're at the mercy of the browser's webrtc implementation decisions.<br/>", "time": "2022-03-23T09:27:54Z"}, {"author": "Stefan Holmer", "text": "@Mo, great, thanks!<br/>", "time": "2022-03-23T09:28:02Z"}, {"author": "Sergio Garcia Murillo", "text": "not for ingest<br/>", "time": "2022-03-23T09:28:02Z"}, {"author": "Kirill Pugin", "text": "@Cullen, not just in browsers :D<br/>", "time": "2022-03-23T09:28:22Z"}, {"author": "Hang Shi", "text": "What is wrong with SRT regarding to large scale deployment?<br/>", "time": "2022-03-23T09:28:43Z"}, {"author": "Alan Frindell", "text": "James' presentation and draft try to explain why quic is interesting for media, but maybe this needs to be articulated more clearly<br/>", "time": "2022-03-23T09:28:47Z"}, {"author": "Sergio Garcia Murillo", "text": "If you want to ingest from a mobile phone with ultra low latency, you will have to make some trade off in quality regardless the technology you use for transport<br/>", "time": "2022-03-23T09:28:52Z"}, {"author": "Magnus Westerlund", "text": "@Juliusz you are correct that that it is implementation, however it is also a question about a control knob that might not exist for remote control. There is an optional RTCP message that allows you to do resolution vs frame rate. Not latency vs quality.<br/>", "time": "2022-03-23T09:29:18Z"}, {"author": "lpardue", "text": "we could rename MoQ to LoQ - latency or quality<br/>", "time": "2022-03-23T09:29:31Z"}, {"author": "Ali Begen", "text": "CMAF chunk header overhead is only applicable to audio (but audio has overhead with everything). The doc says it is the manifest overhead, which is plainly wrong.<br/>", "time": "2022-03-23T09:29:31Z"}, {"author": "Kirill Pugin", "text": "not only audio - video as well, last time I did math overhead at low quality video was in ~~10%<br/>", "time": "2022-03-23T09:30:09Z"}, {"author": "Victor Vasiliev", "text": "In theory, RTP can be used to do high quality streaming, just like it can be used to do anything<br/>", "time": "2022-03-23T09:30:14Z"}, {"author": "Christian Huitema", "text": "Quality vs latency feel like the old QoS debate. You can do so much with signalling, but at some point you are limited by the underlying channel.<br/>", "time": "2022-03-23T09:30:24Z"}, {"author": "Juliusz Chroboczek", "text": "I don't see why the WebRTC API couldn't have a knob that tunes the congestion control algorithm to optimise for quality.&nbsp;&nbsp;Just add a new field to sender.setParameters.<br/>", "time": "2022-03-23T09:30:38Z"}, {"author": "Victor Vasiliev", "text": "In practice, the question is whether fixing problems with WebRTC makes sense compared to building on top of QUIC<br/>", "time": "2022-03-23T09:30:58Z"}, {"author": "Magnus Westerlund", "text": "@Hang, your question maybe something that should be asked to Ying. <br/>", "time": "2022-03-23T09:31:11Z"}, {"author": "Simon Romano", "text": "Agreed<br/>", "time": "2022-03-23T09:31:13Z"}, {"author": "Sergio Garcia Murillo", "text": "on a side note, broadcast quality ingest is not limited by bandwidth, you are only limited by bandwidth/network for user generated content<br/>", "time": "2022-03-23T09:31:41Z"}, {"author": "Ali Begen", "text": "Kirill, you are still missing the main point. Cntainers always come with a cost, but also benefits. that is a different discussion and dont just take the lowest quality as the general case. My comment still stands: no manifest overhead, full stop.<br/>", "time": "2022-03-23T09:32:01Z"}, {"author": "Varun Singh", "text": "For most large scale video conferencing they are using simulcast settings, and the SFU switches to the appropriate simulcast video, which gives them the control needed for controlling quality<br/>", "time": "2022-03-23T09:32:14Z"}, {"author": "Barry Leiba", "text": "We tried make that bandwidth/latency hint when we had the SPUD BoF, and got nowhere with it.<br/>", "time": "2022-03-23T09:32:20Z"}, {"author": "Alan Frindell", "text": "There's a lot of discussion and questions here.&nbsp;&nbsp;If you'd like your comment relayed to the mic, preface with mic:, or please join the queue<br/>", "time": "2022-03-23T09:32:27Z"}, {"author": "James Gruessing", "text": "Sergio: In remote operation, broadcast is definitely limited by bandwidth.<br/>", "time": "2022-03-23T09:32:35Z"}, {"author": "Sergio Garcia Murillo", "text": "I don't think we should prevent a new media protocol over quic even if it overlaps with webrtc. What I don't like is pointing out limitations of webrtc based on current implementations.<br/>", "time": "2022-03-23T09:32:56Z"}, {"author": "Juliusz Chroboczek", "text": "+1<br/>", "time": "2022-03-23T09:33:33Z"}, {"author": "Sergio Garcia Murillo", "text": "+1 james<br/>", "time": "2022-03-23T09:33:37Z"}, {"author": "Christian Huitema", "text": "There is still an issue about what to do when the channel is in fact limiting. Wait or Reduce? (What Harald says)<br/>", "time": "2022-03-23T09:33:45Z"}, {"author": "Sergio Garcia Murillo", "text": "libwebrtc!=webrtc<br/>", "time": "2022-03-23T09:34:37Z"}, {"author": "lpardue", "text": "I've found the material that documents practical limits about WebRTC today very useful, especially when talking to people outside this sphere that want to use webRTC to solve any and every problem<br/>", "time": "2022-03-23T09:35:00Z"}, {"author": "Luke Curley", "text": "unfortunately, libwebrtc == webrtc when web support is a requirement<br/>", "time": "2022-03-23T09:35:28Z"}, {"author": "Kirill Pugin", "text": "I agree, conceptually, nothing in WEbRTC prevents from having the knob, however in practice I have similar experience as Ying...<br/>", "time": "2022-03-23T09:35:28Z"}, {"author": "Juliusz Chroboczek", "text": "Christian: obviously.&nbsp;&nbsp;But video traffic is bursty (keyframes are many times larger than deltas), so if you can afford the latency, you can spread your keyframe over a larger interval and get higher latency at a given target throughput.<br/>", "time": "2022-03-23T09:35:40Z"}, {"author": "Victor Vasiliev", "text": "another issue with srt is that it has only one implementation, and iirc that implemetation does not do much in terms of CC<br/>", "time": "2022-03-23T09:36:03Z"}, {"author": "Simon Romano", "text": "+1 to Sergio<br/>", "time": "2022-03-23T09:37:08Z"}, {"author": "Sergio Garcia Murillo", "text": "+100 to Stephan<br/>", "time": "2022-03-23T09:38:06Z"}, {"author": "Pete Resnick", "text": "Stephan hereby causes coronaries among several transport people. ;-)<br/>", "time": "2022-03-23T09:38:25Z"}, {"author": "Kirill Pugin", "text": "mic: did I hear don't use CC?<br/>", "time": "2022-03-23T09:38:27Z"}, {"author": "Kirill Pugin", "text": ":D<br/>", "time": "2022-03-23T09:38:31Z"}, {"author": "Matt Joras", "text": "\"networks are elastic\" <br/>\"it works just fine\"<br/>", "time": "2022-03-23T09:38:52Z"}, {"author": "Varun Singh", "text": "he said you can \"misuse\" the network for a \"bit longer\"<br/>", "time": "2022-03-23T09:38:55Z"}, {"author": "Dirk Kutscher", "text": "That just means other flows have to yield to the non-CCed traffic.<br/>", "time": "2022-03-23T09:39:02Z"}, {"author": "Christian Huitema", "text": "@Juliusz yes, queuing helps somewhat. But then, queues tend to be either fully empty or completely full, and when full queuing some more does not help.<br/>", "time": "2022-03-23T09:39:07Z"}, {"author": "Ted Hardie", "text": "@Kirill the queue is closed, but what you heard was that \"CC is overrated by this organization.\"<br/>", "time": "2022-03-23T09:39:11Z"}, {"author": "Luke Curley", "text": "congestion means queuing which is terrible for live media<br/>", "time": "2022-03-23T09:39:20Z"}, {"author": "Victor Vasiliev", "text": "^<br/>", "time": "2022-03-23T09:39:27Z"}, {"author": "Luke Curley", "text": "not just the network as a whole<br/>", "time": "2022-03-23T09:39:29Z"}, {"author": "spencerdawkins", "text": "I'm not REMOTELY responsible for any part of MOQ, but we're having awesome discussions here that should probably be more visible to the community here. Suggestions would be to either start mailing list threads on the MOQ mailing list (which is also open during the BOF) or have the scribes/chairs copy the jabber logs into the minutes, and (possibly) clean them up a bit. <br/>", "time": "2022-03-23T09:39:31Z"}, {"author": "Suhas Nandakumar", "text": "+1 on the latencies<br/>", "time": "2022-03-23T09:39:33Z"}, {"author": "James Gruessing", "text": "We already have the terminology in mops-opcons<br/>", "time": "2022-03-23T09:39:36Z"}, {"author": "Justin Uberti", "text": "I liked the ULL50, ULL250 terminology in James' draft<br/>", "time": "2022-03-23T09:40:19Z"}, {"author": "lpardue", "text": "+1<br/>", "time": "2022-03-23T09:40:27Z"}, {"author": "Murray Kucherawy", "text": "+1 to Spencer.<br/>", "time": "2022-03-23T09:40:37Z"}, {"author": "Jake Holland", "text": "yes, ull50 is a good trm<br/>", "time": "2022-03-23T09:40:39Z"}, {"author": "hta", "text": "Ultra low latency is when musicians can play together, which is less than 20 ms - preferably less than 5.<br/>", "time": "2022-03-23T09:40:46Z"}, {"author": "Sergio Garcia Murillo", "text": "I agree with spencer, most of the \"issues\" pointed out with webrtc are going to happen with any low latency implementation protocol<br/>", "time": "2022-03-23T09:40:50Z"}, {"author": "Juliusz Chroboczek", "text": "hta: drummers or violinists?<br/>", "time": "2022-03-23T09:41:07Z"}, {"author": "Jake Holland", "text": "ull10 is about where musicians can play together<br/>", "time": "2022-03-23T09:41:10Z"}, {"author": "Justin Uberti", "text": "it depends a lot on the instrument and type of music<br/>", "time": "2022-03-23T09:41:30Z"}, {"author": "Pete Resnick", "text": "You could remove the \"ul\" part. l10 vs l50 vs l100000000...<br/>", "time": "2022-03-23T09:41:46Z"}, {"author": "Jake Holland", "text": "sure. but does anything over 10 work?<br/>", "time": "2022-03-23T09:41:47Z"}, {"author": "Lars Eggert", "text": "+1 to cullen. make cc pluggable and factor our the problem<br/>", "time": "2022-03-23T09:41:51Z"}, {"author": "Massimo Nilo", "text": "+1 to Spencer \"copy the jabber logs into the minutes\"<br/>", "time": "2022-03-23T09:41:52Z"}, {"author": "hta", "text": "@juliusz both. The size of a symphony orchestray is chiefly set by the audio propagation delay between the 1st violin and the cellos.<br/>", "time": "2022-03-23T09:41:53Z"}, {"author": "Matt Joras", "text": "I find the discussion around QUIC congestion control confusing. The only documented \"QUIC congestion control\" is based on Reno. The QUIC WG is not chartered to work on congestion control.<br/>", "time": "2022-03-23T09:41:54Z"}, {"author": "lpardue", "text": "+1 to remove \"ul\"<br/>", "time": "2022-03-23T09:42:07Z"}, {"author": "Chris Lemmons", "text": "Can we not have a number that starts with a lower-case l, too? :)<br/>", "time": "2022-03-23T09:42:42Z"}, {"author": "Jake Holland", "text": "capitalize to disambiguate from a leading one is also nice<br/>", "time": "2022-03-23T09:42:42Z"}, {"author": "Jake Holland", "text": "L20<br/>", "time": "2022-03-23T09:42:44Z"}, {"author": "Jake Holland", "text": "L15<br/>", "time": "2022-03-23T09:42:47Z"}, {"author": "hta", "text": "+1 to L5.<br/>", "time": "2022-03-23T09:42:48Z"}, {"author": "Maxim Sharabayko", "text": "@Hang &gt; What is wrong with SRT regarding to large scale deployment?The main blocker Ying was talking about is that CDNs don't know they get SRT, but this of it as of some UDP traffic without any connection ID to understand how to route it.And for that putting SRT on top of QUIC instead of CDNs learning SRT is a possible way to go.<br/>", "time": "2022-03-23T09:42:51Z"}, {"author": "Suhas Nandakumar", "text": "i like what was suggested, don't use adjectives, just call them as they are latency &lt; 50, latency 50-250 and so on<br/>", "time": "2022-03-23T09:42:56Z"}, {"author": "Pete Resnick", "text": "(I love a good bikeshed.)<br/>", "time": "2022-03-23T09:43:13Z"}, {"author": "Jana Iyengar", "text": "Yeah, what Cullen and Matt said. Let's not talk about CC here, that is not productive.<br/>", "time": "2022-03-23T09:43:15Z"}, {"author": "Barry Leiba", "text": "hta: That effect is why I hate when musicians get the audience to clap along with the music.&nbsp;&nbsp;It's not \"along with\" anything as the audience hears it.<br/>", "time": "2022-03-23T09:43:21Z"}, {"author": "Juliusz Chroboczek", "text": "(The pandemic appears to have had the consequence of making the chat more interesting than the room.)<br/>", "time": "2022-03-23T09:43:23Z"}, {"author": "Sergio Garcia Murillo", "text": "but CC is the main source of all quality/latency issues with low latency streaming<br/>", "time": "2022-03-23T09:43:44Z"}, {"author": "Justin Uberti", "text": "We had the discussion about music latency in the previous session. Marching bands typically have to deal with &gt;50ms latency between the drumline and other instruments.<br/>", "time": "2022-03-23T09:43:59Z"}, {"author": "Cullen Jennings", "text": "The chat was always more interesting than the mic line :-)<br/>", "time": "2022-03-23T09:44:08Z"}, {"author": "Christian Huitema", "text": "WebRTC looks a bit like a baroque cathedral. Some more ornaments would certainly be even more so<br/>", "time": "2022-03-23T09:44:17Z"}, {"author": "David Schinazi", "text": "The brakes on my car are the main source of me slowing down, but I'd rather not remove them...<br/>", "time": "2022-03-23T09:44:27Z"}, {"author": "Hang Shi", "text": "@Maxim So you are saying anything other than QUIC(UDP with connection ID) is hard to deploy, is that right?<br/>", "time": "2022-03-23T09:44:29Z"}, {"author": "Craig Taylor", "text": "@Luke ...I love the slides tbh<br/>", "time": "2022-03-23T09:44:41Z"}, {"author": "Suhas Nandakumar", "text": "+1 on tak CC discussions elsewhere where we can focus on the specific adjustments needs to be done<br/>", "time": "2022-03-23T09:44:43Z"}, {"author": "hta", "text": "@suhas the CC *is* the specific adjustments that need to be done.....<br/>", "time": "2022-03-23T09:45:28Z"}, {"author": "Craig Taylor", "text": "Indeed: CC needs to be pluggable is the only thing we need to take here...<br/>", "time": "2022-03-23T09:45:35Z"}, {"author": "Jake Holland", "text": "@sergio: I'd think it's chieflly the network impairment especially under congestion (loss, reordering, jitter, etc).&nbsp;&nbsp;The congestion control response can exacerbate it, but the core problem is the way the packet stream timing gets messed up.<br/>", "time": "2022-03-23T09:45:36Z"}, {"author": "Meetecho", "text": "It also depends on the musician: I can't keep up with myself when I play on a local backing track :)<br/>", "time": "2022-03-23T09:45:37Z"}, {"author": "David Schinazi", "text": "(but yes I agree that we should not rathole on congestion control here, that's a discussion best held over beer)<br/>", "time": "2022-03-23T09:45:44Z"}, {"author": "Hang Shi", "text": "You can drop some data to get low latency and acceptable quality. CC is not the only way to go.<br/>", "time": "2022-03-23T09:45:56Z"}, {"author": "Pete Resnick", "text": "Ah, I remember the days when you could place bets on the time to someone saying the word \"multicast\" with this kind of presentation.<br/>", "time": "2022-03-23T09:46:15Z"}, {"author": "hta", "text": "@hang shi Dropping data is one (perfectly valid) form of CC.<br/>", "time": "2022-03-23T09:46:18Z"}, {"author": "Kirill Pugin", "text": "re WebRTC vs. world: I wonder if there is a chance we can unify ingest and distribution protocols<br/>", "time": "2022-03-23T09:46:21Z"}, {"author": "Murray Kucherawy", "text": "Beer resolves congestion control problems.<br/>", "time": "2022-03-23T09:46:27Z"}, {"author": "Juliusz Chroboczek", "text": "Christian: WebRTC is not a baroque cathedral, it's more like the plumbing system in my apartment block, which has been extended since 1917 by the different tenants with no central coordination.<br/>", "time": "2022-03-23T09:46:28Z"}, {"author": "Christian Huitema", "text": "That too...<br/>", "time": "2022-03-23T09:46:51Z"}, {"author": "Matt Joras", "text": "Hang: I think the point is that CDNs and in general the deployments looking to have an ingest solution already have infrastructure built up around QUIC and TCP. TCP has obvious problems. QUIC is easy to adapt hence the interest in adapting it for ingest.<br/>", "time": "2022-03-23T09:47:04Z"}, {"author": "Mo Zanaty", "text": "@Christian, baroque or b-roke?<br/>", "time": "2022-03-23T09:47:26Z"}, {"author": "Pete Resnick", "text": "As far as I can tell, *you* don't really have to worry so much about CC so long as everyone else is still worrying about CC. ;-)<br/>", "time": "2022-03-23T09:47:31Z"}, {"author": "Jake Holland", "text": "lol, yes.&nbsp;&nbsp;that is true.<br/>", "time": "2022-03-23T09:47:49Z"}, {"author": "hta", "text": "@pete, if everyone else is also me, I have to worry :-)<br/>", "time": "2022-03-23T09:48:04Z"}, {"author": "Christian Huitema", "text": "I was being nice. There is some aesthetic value in baroque cathedrals (if you forget the ugly bits about the wars of religion.)<br/>", "time": "2022-03-23T09:48:08Z"}, {"author": "Pete Resnick", "text": "@hta: \"Everyone else\" is *never* me. I am an individual!<br/>", "time": "2022-03-23T09:48:56Z"}, {"author": "James Gruessing", "text": "The soccer example isn't so good when you consider that existing OTT viewers will hear their neighbours watching on Cable/DTT/etc scream when a goal is scored and find out 45 seconds later.<br/>", "time": "2022-03-23T09:48:56Z"}, {"author": "Pete Resnick", "text": "(So Monty Python tells me.)<br/>", "time": "2022-03-23T09:49:08Z"}, {"author": "lpardue", "text": "James, what if we just delayed everyone by the same fixed time after it really happened? :D<br/>", "time": "2022-03-23T09:49:29Z"}, {"author": "Kirill Pugin", "text": "^ viewer sync is a good use-case to consider<br/>", "time": "2022-03-23T09:50:07Z"}, {"author": "Alan Frindell", "text": "spencer: is that a clarifying question or can you wait until the end?<br/>", "time": "2022-03-23T09:50:09Z"}, {"author": "Kirill Pugin", "text": "it doesn't have to me ULL, can be 30s latency, but all viewers seeing \"the same frame\"<br/>", "time": "2022-03-23T09:50:34Z"}, {"author": "Maxim Sharabayko", "text": "@Hang Everything that CDNs don't think makes sense to consider, probably in terms of cost to implement / the share among other protocols.<br/>", "time": "2022-03-23T09:50:54Z"}, {"author": "Ali Begen", "text": "@James, if your OTT is still 45 seconds behind live (that is around 35 seconds behind you cable/satellite), you can change your OTT provider. Today, they have everything to do this on par with cable/satellite which is the norm for broadcast<br/>", "time": "2022-03-23T09:50:58Z"}, {"author": "Ali Begen", "text": "You would never need a soccer OTT stream at a few seconds (I don't know much about the betting that indeed requires that kind of latency - all the bettings I know need you to bet in advance of the game)<br/>", "time": "2022-03-23T09:52:18Z"}, {"author": "Simon Romano", "text": "This slide is biased against WebRTC.<br/>", "time": "2022-03-23T09:52:35Z"}, {"author": "Maxim Sharabayko", "text": ":)<br/>", "time": "2022-03-23T09:53:00Z"}, {"author": "Pete Resnick", "text": "One of my old Qualcomm friends would by now start saying something about fountain codes and FEC.<br/>", "time": "2022-03-23T09:53:34Z"}, {"author": "James Gruessing", "text": "Ali: \"changing provider\" is a trivialisation of the problem space - consider DTT/Sat/Cable etc outputs don't have pesky buffering, ABR algorithms, etc.<br/>", "time": "2022-03-23T09:54:10Z"}, {"author": "hta", "text": "@luke we need to talk about how to report issues with webrtc....<br/>", "time": "2022-03-23T09:54:12Z"}, {"author": "Simon Romano", "text": "When I teach my class I say the exact opposite: nothing that leverages HTTP will ever be the rght choice for live multiimedia experiences :-)<br/>", "time": "2022-03-23T09:54:16Z"}, {"author": "Justin Uberti", "text": "seems like if game streaming can work over WebRTC we can get simpler streaming cases working as well. But that might be hitting on the end-to-end webrtc topic that Luke alludes to.<br/>", "time": "2022-03-23T09:54:26Z"}, {"author": "Ali Begen", "text": "@Simon, I dont know what you teach but I'd recommend not saying something like that to your students. Largest sports event have been nicely served over HTTP for many years now.<br/>", "time": "2022-03-23T09:55:55Z"}, {"author": "Alan Frindell", "text": "I think implementing WARP or something like it using H3 would require HTTP server push.<br/>", "time": "2022-03-23T09:55:59Z"}, {"author": "James Gruessing", "text": "Simon: HTTP is absolutely fine for On Demand use cases, serving immutable lumps of media that have no latency requisite is a well solved problem. Live and Interactive however...<br/>", "time": "2022-03-23T09:56:05Z"}, {"author": "Simon Romano", "text": "Agreed on the \"On Demand\" thing<br/>", "time": "2022-03-23T09:56:25Z"}, {"author": "Ali Begen", "text": "@James, you can surive with LL OTT today on part with cable/satellite, there are examples out there. Yes, you might stall more likely, but you don't have to carry your settop around to watch a game.<br/>", "time": "2022-03-23T09:57:54Z"}, {"author": "Juliusz Chroboczek", "text": "Simon, Ali, I think you don't have the same concept of what live latencies are acceptable.<br/>", "time": "2022-03-23T09:57:57Z"}, {"author": "Roni Even", "text": "latency vs quality reminds me the videoTemporalSpatialTradeOff parameter that had a value between 0 to 31 but not clear about the actual tradeoff and how to evaluate it<br/>", "time": "2022-03-23T09:58:44Z"}, {"author": "Craig Taylor", "text": "We talked about video use cases when looking at priorities and that was one of the reasons why negotitation was included, so alternate schemes could be used...<br/>", "time": "2022-03-23T09:59:10Z"}, {"author": "lpardue", "text": "negotiation is not included Craig :) only a deprecation of the old H2 priorities in H2<br/>", "time": "2022-03-23T09:59:44Z"}, {"author": "Kirill Pugin", "text": "mic: refreshing manifest for LL-DASH is not fun...<br/>", "time": "2022-03-23T09:59:45Z"}, {"author": "Craig Taylor", "text": "bah<br/>", "time": "2022-03-23T09:59:52Z"}, {"author": "Craig Taylor", "text": "clearly not paying attention<br/>", "time": "2022-03-23T10:00:08Z"}, {"author": "James Gruessing", "text": "Ali: I disagree, and my hot take is that LL[HLS|DASH] is a bit of a bodge. CTE, server push, delta playlists etc are trying to push square peg protocols into a round hole problems and have some not-so-great limitations in scale and overhead.<br/>", "time": "2022-03-23T10:00:34Z"}, {"author": "Victor Vasiliev", "text": "As long as you don't reference stream IDs, almost any QUIC protocol can run over WebTransport<br/>", "time": "2022-03-23T10:00:43Z"}, {"author": "lpardue", "text": "forgot to say at the mic: needing per-request signals to express priority introduces an immediate latency cost. Whereas my understanding of Warp's needs is that a declaration that the session is best served LIFO will avoid that entirely<br/>", "time": "2022-03-23T10:00:56Z"}, {"author": "Victor Vasiliev", "text": "There's an open issue for controlling prioritization on WebTransport streams in W3C.&nbsp;&nbsp;We don't have any progress on it mostly because no one has been actively asking to do that<br/>", "time": "2022-03-23T10:02:03Z"}, {"author": "lpardue", "text": "and ignoring extensible priorities: you need your QUIC implemention to let the application have some control over how the application-data-bearing frames (STREAM and DATAGRAM) are multiplexed when active and concurrent<br/>", "time": "2022-03-23T10:02:17Z"}, {"author": "lpardue", "text": "supporting control at the QUIC layer and still ignoring H3 priority signals is totally allowed :)<br/>", "time": "2022-03-23T10:03:16Z"}, {"author": "Ali Begen", "text": "@James, you need to be more specific than that. Please explain what problems LL-DASH has. Nobody claims it is perfect but I argue it is far better than anything we have today. Educate me if you think otherwise. For LL-HLS, there are studies out there listing all the complexities it has so that is a rather well-known (at least for me) topic.<br/>", "time": "2022-03-23T10:03:36Z"}, {"author": "Luke Curley", "text": "yeah, the gist of warp is that newer requests need to finish first, which is backwards from traditional HTTP requests<br/>", "time": "2022-03-23T10:04:03Z"}, {"author": "hta", "text": "anyone caught which number he was quoting for conference sizes?<br/>", "time": "2022-03-23T10:05:24Z"}, {"author": "Lorenzo Miniero", "text": "1000 I think<br/>", "time": "2022-03-23T10:05:33Z"}, {"author": "hta", "text": "thanks!<br/>", "time": "2022-03-23T10:05:43Z"}, {"author": "David Schinazi", "text": "If we allowed them to be active speakers it'd be a mess :rofl:<br/>", "time": "2022-03-23T10:06:12Z"}, {"author": "Jonathan Lennox", "text": "As I understand it Meetecho is indeed switching between streaming and interactive as you request permission to speak.<br/>", "time": "2022-03-23T10:06:18Z"}, {"author": "Sergio Garcia Murillo", "text": "kind of tired of the Webrtc does not scale argument<br/>", "time": "2022-03-23T10:06:21Z"}, {"author": "Eric Kinnear", "text": "Luke: Makes sense, my gut reaction that that fits nicely into the sort of thing that's good to address with the new HTTP priorities is complicated by the question we asked at the time for the other priority things: \"Is this something the server can't figure out by itself, does it really need the client to send a signal on the wire for it?\" and I'm not sure how I feel about that for \"newer requests should finish first\"<br/>", "time": "2022-03-23T10:06:31Z"}, {"author": "Lorenzo Miniero", "text": "Jonathan yes, that's how we're serving the IETF meeting<br/>", "time": "2022-03-23T10:06:33Z"}, {"author": "Simon Romano", "text": "Ack to Jonathan<br/>", "time": "2022-03-23T10:06:37Z"}, {"author": "Pete Resnick", "text": "Live television news always has 5-second delays when they go to reporters in the field due to satellite links. Not much you can do about some kinds of latency.<br/>", "time": "2022-03-23T10:06:54Z"}, {"author": "Lorenzo Miniero", "text": "+1 Sergio<br/>", "time": "2022-03-23T10:07:00Z"}, {"author": "Sergio Garcia Murillo", "text": "how a quic based protocol be different in scaling to webrtc?<br/>", "time": "2022-03-23T10:07:12Z"}, {"author": "Simon Romano", "text": "+1K Sergio<br/>", "time": "2022-03-23T10:07:21Z"}, {"author": "lpardue", "text": "+ Eric K - a server could look for other headers (content-type?) to decide to do different things<br/>", "time": "2022-03-23T10:07:29Z"}, {"author": "Luke Curley", "text": "QUIC and WebRTC are basically the same for scaling (CPU performance)<br/>", "time": "2022-03-23T10:07:36Z"}, {"author": "Varun Singh", "text": "some of the issues with large conferencing is handling/rendering audio on the endpoint (mostly because of browser limitations)<br/>", "time": "2022-03-23T10:07:41Z"}, {"author": "Jonathan Lennox", "text": "Pete: If the reporters could broadcast over 5G rather than satellite with the protocol we define, we could solve that<br/>", "time": "2022-03-23T10:07:44Z"}, {"author": "Juliusz Chroboczek", "text": "Sergio, look at the bright side.&nbsp;&nbsp;If this meeting makes the HTTP people aware that \"sub-second latency\" is nothing to brag about, it will have done something useful.<br/>", "time": "2022-03-23T10:07:46Z"}, {"author": "Simon Romano", "text": "WebRTC scales as long as you're able to mak it scale (also architecture-wise)<br/>", "time": "2022-03-23T10:07:47Z"}, {"author": "Luke Curley", "text": "although \"scaling\" includes CDN support<br/>", "time": "2022-03-23T10:07:50Z"}, {"author": "Sergio Garcia Murillo", "text": "it is not easy, but we are able to do end to end webrtc streaming to hundred thousands viewers<br/>", "time": "2022-03-23T10:08:02Z"}, {"author": "James Gruessing", "text": "Pete: Where sat is still used (and it's being used less for domestic connectivity). Bonded 4G is more prevailent, 5G will supercede it<br/>", "time": "2022-03-23T10:08:06Z"}, {"author": "Kirill Pugin", "text": "I think the important part \"it's not easy\", imho<br/>", "time": "2022-03-23T10:08:35Z"}, {"author": "Victor Vasiliev", "text": "Well, the difference between QUIC and RTP in terms of CPU is that the optimizations made for serving HTTP can be reused<br/>", "time": "2022-03-23T10:08:45Z"}, {"author": "Kirill Pugin", "text": "@Sergio<br/>", "time": "2022-03-23T10:08:46Z"}, {"author": "Sergio Garcia Murillo", "text": "you think that doing that over quic would be easier?<br/>", "time": "2022-03-23T10:08:50Z"}, {"author": "Sergio Garcia Murillo", "text": "if so, why?<br/>", "time": "2022-03-23T10:08:52Z"}, {"author": "Simon Romano", "text": "@Kirill Life is not easy by definition<br/>", "time": "2022-03-23T10:09:09Z"}, {"author": "Juliusz Chroboczek", "text": "Sergio, I suspect that people are investing millions into QUIC proxying infratructure, and they don't wish to repeat the effort with RTP proxying infrastructure.&nbsp;&nbsp;It's an understandable concern.<br/>", "time": "2022-03-23T10:09:15Z"}, {"author": "Matt Joras", "text": "+1 Victor. The whole value proposition of QUIC relies on the fact that it is used for other things in a CDN/infrastructure. WebRTC is not.<br/>", "time": "2022-03-23T10:09:15Z"}, {"author": "Sergio Garcia Murillo", "text": "victor, but that is a chicken and egg situation<br/>", "time": "2022-03-23T10:09:25Z"}, {"author": "Kirill Pugin", "text": "it's already done :D - H3 is deployed<br/>", "time": "2022-03-23T10:09:36Z"}, {"author": "Matt Joras", "text": "Yeah it's not a chicken and egg problem. The chicken is walking around and clucking.<br/>", "time": "2022-03-23T10:10:17Z"}, {"author": "Sergio Garcia Murillo", "text": "I buy the \"we alredy have quic support and we want to use it for media streamin\" argument, it is perfectly reasonable<br/>", "time": "2022-03-23T10:10:26Z"}, {"author": "Justin Uberti", "text": "combining signaling and media over the same protocol would be pretty nice in many ways.<br/>", "time": "2022-03-23T10:10:34Z"}, {"author": "Sergio Garcia Murillo", "text": "what I don't buy is \"webrtc can't scale\"<br/>", "time": "2022-03-23T10:10:47Z"}, {"author": "Hang Shi", "text": "Agree. There is nothing fundamental about webRTC that makes it hard to scale.<br/>", "time": "2022-03-23T10:11:31Z"}, {"author": "Sergio Garcia Murillo", "text": "I disagree about the combining signaling and media over same transport is a nice feature, that is one of my issues about scaling rtmp vs webrtc<br/>", "time": "2022-03-23T10:11:33Z"}, {"author": "Kirill Pugin", "text": "@Sergio - I agree, it can scale, I think we need take into consideration how hard/easy that is, though<br/>", "time": "2022-03-23T10:11:49Z"}, {"author": "Sergio Garcia Murillo", "text": "hard/easy depends on your proficiency on the technology also ;)<br/>", "time": "2022-03-23T10:12:16Z"}, {"author": "Hang Shi", "text": "Actually, Alibaba deploy large scale livestreaming using webRTC<br/>", "time": "2022-03-23T10:12:17Z"}, {"author": "Kirill Pugin", "text": "side note I think there is to much WebRTC mentioning :D<br/>", "time": "2022-03-23T10:12:26Z"}, {"author": "Ali Begen", "text": "If you throw at it enough money, it will surely scale.<br/>", "time": "2022-03-23T10:12:29Z"}, {"author": "Sergio Garcia Murillo", "text": "anyway, I am not against media over quic, just against saying that webrtc doesn't work for the same use case<br/>", "time": "2022-03-23T10:12:37Z"}, {"author": "Simon Romano", "text": "@Justin I see both pros and cons there<br/>", "time": "2022-03-23T10:12:42Z"}, {"author": "Juliusz Chroboczek", "text": "Sergio, I'm with you, but there's no denying the WebRTC stack is a mess.&nbsp;&nbsp;Amicus Plato, sed magia amica veritas.<br/>", "time": "2022-03-23T10:12:56Z"}, {"author": "Luke Curley", "text": "Warp is live for a fraction of Twitch Chrome users but it's going to be an absolute pain to optimize it to reach TCP levels<br/>", "time": "2022-03-23T10:13:02Z"}, {"author": "Kirill Pugin", "text": "@Hang, have you compared it to anything H3 based? How you do scrubbing back with WebRTC?<br/>", "time": "2022-03-23T10:13:05Z"}, {"author": "Matt Joras", "text": "There's nothing fundamentally blocking about using WebRTC, yet this is experience from people running actual infrastructure saying these things. While it may not be fundamentally true, it seems there's evidence it's practically difficult, and that's why there's a desire for other solutions.<br/>", "time": "2022-03-23T10:13:30Z"}, {"author": "Justin Uberti", "text": "just saying it would be nice to be able to simply open a grpc connection to a hostname and start getting low latency media over that connection.<br/>", "time": "2022-03-23T10:13:40Z"}, {"author": "Simon Romano", "text": "Agreed<br/>", "time": "2022-03-23T10:13:55Z"}, {"author": "Pete Resnick", "text": "I'll ask it at the mic, but I still don't see how any of this is related to QUIC (other than simply saying, \"This stuff will run better over QUIC\", which doesn't need any protocol work).<br/>", "time": "2022-03-23T10:14:30Z"}, {"author": "Juliusz Chroboczek", "text": "Justin: you really want to have the network drop packets on congestion if you're into low latency.&nbsp;&nbsp;(Hopefully the bottleneck has implemented a smart AQM.)<br/>", "time": "2022-03-23T10:14:47Z"}, {"author": "Jonathan Lennox", "text": "Pete: this is APP-layer work not TSV-layer IMO - i.e. *how* best to run it over QUIC.<br/>", "time": "2022-03-23T10:15:09Z"}, {"author": "Pete Resnick", "text": "@Jonathan: But wouldn't the same kinds of things make it run best over non-QUIC?<br/>", "time": "2022-03-23T10:15:38Z"}, {"author": "Sergio Garcia Murillo", "text": "justin, i agree, but I would prefer to avoid having to rely on network load balance, it increases my cloud provider costs<br/>", "time": "2022-03-23T10:15:48Z"}, {"author": "Jonathan Lennox", "text": "Not if it's specifically taking advantage of QUIC features<br/>", "time": "2022-03-23T10:15:55Z"}, {"author": "James Gruessing", "text": "Ali: The tl;dr is LL versions change the requirements for state of playback back to edge and origin. Non-LL doesn't need to know where the player is at, and edge can be \"generic\". There's plenty of gains for us coming up with a more cleanly delineated, simpler solution and have both lower latency *and* scale.<br/>", "time": "2022-03-23T10:16:04Z"}, {"author": "Magnus Westerlund", "text": "Pete, to me you are correct. QUIC is only an enabler. It is also in some sense the straw that broke the back the wall of actually look at new media delivery protocol.<br/>", "time": "2022-03-23T10:16:13Z"}, {"author": "Sergio Garcia Murillo", "text": "so a redirection feature would be nice in that case, so I can do load balance inside my service<br/>", "time": "2022-03-23T10:16:28Z"}, {"author": "Justin Uberti", "text": "@sergio being able to use off-the-shelf stuff like HTTP LBs is one of the key goals here, IMHO.<br/>", "time": "2022-03-23T10:16:34Z"}, {"author": "Hang Shi", "text": "WebRTC has lower latency compared to H3 but it can not support scrubbing back. Alibaba disable that feature for the viewers.<br/>", "time": "2022-03-23T10:16:46Z"}, {"author": "Luke Curley", "text": "Warp and RUSH take advantage of QUIC functionality<br/>", "time": "2022-03-23T10:16:53Z"}, {"author": "Kirill Pugin", "text": "@Hang what about quality?<br/>", "time": "2022-03-23T10:17:03Z"}, {"author": "Luke Curley", "text": "QuicR seems like a layer on top<br/>", "time": "2022-03-23T10:17:04Z"}, {"author": "Ali Begen", "text": "@James, I feel like you are misinterpreting how LL-DASH works. LL-HLS has the exact problem you mentioned but LL-DASH simply does not depend on any of it<br/>", "time": "2022-03-23T10:17:10Z"}, {"author": "Pete Resnick", "text": "@Jonathan: But that's not QUIC specific really. That's just saying, \"If you're going to do this over TCP, you're going to have to implement dealing with HoL blocking.\"<br/>", "time": "2022-03-23T10:17:15Z"}, {"author": "Sergio Garcia Murillo", "text": "HTTP LBs has extra cost in all cloud providers, it is affordable now because the amount of that you send is not huge<br/>", "time": "2022-03-23T10:17:18Z"}, {"author": "Ted Hardie", "text": "Magnus's point is good:&nbsp;&nbsp;if it is time to create a new media delivery protocol, we have two choices based on worked examples:&nbsp;&nbsp;QUIC and WebRTC.&nbsp;&nbsp;QUIC has some features that made it scaling in fan-out situations better.<br/>", "time": "2022-03-23T10:17:20Z"}, {"author": "Sergio Garcia Murillo", "text": "but if you send media over the LB connection, the costs will be huge<br/>", "time": "2022-03-23T10:17:31Z"}, {"author": "Victor Vasiliev", "text": "Sure, but it's also much lower QPS<br/>", "time": "2022-03-23T10:17:50Z"}, {"author": "Hang Shi", "text": "Based on my experience, quality is good too. Alibaba must do a lot of tweaking in webRTC.<br/>", "time": "2022-03-23T10:18:00Z"}, {"author": "Kirill Pugin", "text": "@Sergio, what do you mean by not huge? What huge is?<br/>", "time": "2022-03-23T10:18:02Z"}, {"author": "Craig Taylor", "text": "Consolidate/enable: The existing solutions all work, but use different transports/code.... Consolidating here should improve interop/code reuse and also help with some of the in path elements such as CID routing...<br/>", "time": "2022-03-23T10:18:07Z"}, {"author": "Justin Uberti", "text": "I do feel pretty strongly that you shouldn't have to build your own LBs to deploy low latency apps.<br/>", "time": "2022-03-23T10:18:16Z"}, {"author": "Pete Resnick", "text": "I don't think my question is \"clarifying\".<br/>", "time": "2022-03-23T10:18:22Z"}, {"author": "Simon Romano", "text": "I strongly disagree also with the argument against RTP and multicast. As outdated as it might look, I do believe this might still play a fundamental role, especially in the core part of the distribution network.<br/>", "time": "2022-03-23T10:18:51Z"}, {"author": "Justin Uberti", "text": "That's the sort of thing people point at when they say it's hard to deploy webrtc apps - most of the public cloud infra that exists for HTTP doesn't really work.<br/>", "time": "2022-03-23T10:19:29Z"}, {"author": "Hang Shi", "text": "Actually IPTV is using RTP and multicast.<br/>", "time": "2022-03-23T10:19:31Z"}, {"author": "Lorenzo Miniero", "text": "We do make use uf multicast in scaling our WebRTC distribution in some scenarios (some of our customers do as well). I did a presentation in MBONED a few meetings ago<br/>", "time": "2022-03-23T10:19:31Z"}, {"author": "Craig Taylor", "text": "...there you go @pete<br/>", "time": "2022-03-23T10:19:53Z"}, {"author": "Simon Romano", "text": "And it simply works.<br/>", "time": "2022-03-23T10:19:55Z"}, {"author": "Pete Resnick", "text": "@Craig: Whoops, did I miss something?<br/>", "time": "2022-03-23T10:20:15Z"}, {"author": "James Gruessing", "text": "Hang: Where multicast exists. There are some cable providers with inherited networks that have multicast islands or just can't do it and end up doing even.. RTSP...<br/>", "time": "2022-03-23T10:20:46Z"}, {"author": "Jana Iyengar", "text": "Exactly. What Cullen's saying.<br/>", "time": "2022-03-23T10:20:52Z"}, {"author": "Sergio Garcia Murillo", "text": "GCP: Inbound data processed by load balancer&nbsp;&nbsp;&nbsp;&nbsp;$0.008&nbsp;&nbsp;&nbsp;&nbsp;Per GB<br/>", "time": "2022-03-23T10:21:01Z"}, {"author": "lpardue", "text": "IME extant multicast networks are not friendly to evolution<br/>", "time": "2022-03-23T10:21:23Z"}, {"author": "Sergio Garcia Murillo", "text": "that's 10% of our service cost per GB<br/>", "time": "2022-03-23T10:21:46Z"}, {"author": "Christian Huitema", "text": "Does anybody actually use layered encodings?<br/>", "time": "2022-03-23T10:23:21Z"}, {"author": "Varun Singh", "text": "Temporal layers, yes, a lot. Spatial layers, less or leaning no.<br/>", "time": "2022-03-23T10:24:04Z"}, {"author": "Juliusz Chroboczek", "text": "Christian: temporal scalability with VP8/VP9 is easy.<br/>", "time": "2022-03-23T10:24:14Z"}, {"author": "Kirill Pugin", "text": "WebRTC :D<br/>", "time": "2022-03-23T10:24:14Z"}, {"author": "hta", "text": "@christian the default WebRTC deployment uses temporal layers.<br/>", "time": "2022-03-23T10:24:19Z"}, {"author": "Jake Holland", "text": "+1 @Simon, multicast is not as hopeless as people think.<br/>", "time": "2022-03-23T10:24:43Z"}, {"author": "hta", "text": "Lots of noise around svc for webrtc just now - see webrtc-svc specs and intent-to-implement stuff around it.<br/>", "time": "2022-03-23T10:24:48Z"}, {"author": "Mo Zanaty", "text": "Temporal layers are not really layers to codec people.<br/>", "time": "2022-03-23T10:24:51Z"}, {"author": "Varun Singh", "text": "it feels that cullen's proposal is a \"pull\" model and ergo caching in CDNs<br/>", "time": "2022-03-23T10:25:02Z"}, {"author": "Juliusz Chroboczek", "text": "Mo: fair enough.&nbsp;&nbsp;But my concern with streams per GOP holds even for temporal.<br/>", "time": "2022-03-23T10:25:12Z"}, {"author": "Jake Holland", "text": "however, I think multicast is less about the core than about being efficient on the actual broadcast media (the last mile cable loops/fiber)<br/>", "time": "2022-03-23T10:25:21Z"}, {"author": "Victor Vasiliev", "text": "I believe it's push? It has subscribe as a fundamental verb<br/>", "time": "2022-03-23T10:25:30Z"}, {"author": "Jake Holland", "text": "you can scale out the core cheaper than deploying multicast, but you cannot lay new cable to all the home cheaper<br/>", "time": "2022-03-23T10:25:42Z"}, {"author": "Hang Shi", "text": "+1<br/>", "time": "2022-03-23T10:26:12Z"}, {"author": "Varun Singh", "text": "compared to arguments of scaling webrtc, which is a set up and then the servers push. Servers also make the decisions and hide those decisions from the clients. aka, SFUs doing simulcast switches<br/>", "time": "2022-03-23T10:26:15Z"}, {"author": "hta", "text": "stream per dependency chain may make sense - when you fall too far behind (which may be whenever you lose a frame), you terminate that stream and start a new one, with a leading i-frame....<br/>", "time": "2022-03-23T10:26:21Z"}, {"author": "Luke Curley", "text": "@hta absolutely<br/>", "time": "2022-03-23T10:26:37Z"}, {"author": "Simon Romano", "text": "@Jake the last mile is one more point where you can take advantage of multicast (DAZN s indeed doing that in Italy, when the last mile is operated by a specific ISP).<br/>", "time": "2022-03-23T10:26:48Z"}, {"author": "Luke Curley", "text": "my idea for Warp is that each layer of the pyramid is a QUIC stream<br/>", "time": "2022-03-23T10:27:19Z"}, {"author": "Dirk Kutscher", "text": "+1 to Spencer<br/>", "time": "2022-03-23T10:27:19Z"}, {"author": "Cullen Jennings", "text": "Tor uses relays to avoid centralization. So did Skype. <br/>", "time": "2022-03-23T10:27:27Z"}, {"author": "hta", "text": "sigh ... the Internet will get more centalized, and what we do here will be blamed for it, whehter it is the cause of the centralization or not.<br/>", "time": "2022-03-23T10:27:47Z"}, {"author": "Pete Resnick", "text": "There we go! At the mic even. \"Multicast!\"<br/>", "time": "2022-03-23T10:28:43Z"}, {"author": "Varun Singh", "text": "I am thinking through the \"named content\" parts for cacheability. I am assuming those can be pulled.<br/>", "time": "2022-03-23T10:28:44Z"}, {"author": "Craig Taylor", "text": "BT run a multicast network<br/>", "time": "2022-03-23T10:29:05Z"}, {"author": "Varun Singh", "text": "assuming the CDN cached that named contnet<br/>", "time": "2022-03-23T10:29:07Z"}, {"author": "lpardue", "text": "I can only get my printer to work via USB<br/>", "time": "2022-03-23T10:29:18Z"}, {"author": "Brian Trammell", "text": "well yes. but care should be taken to make sure the interfaces in the MoQ architecture don't *force* you to build a centralizing machines<br/>", "time": "2022-03-23T10:29:25Z"}, {"author": "Brian Trammell", "text": "i'd watch TV at home over multicast, if I watched TV.<br/>", "time": "2022-03-23T10:29:36Z"}, {"author": "Brian Trammell", "text": "mainly i just listen to my neighbors yelling to figure out what's going in with the sportsball<br/>", "time": "2022-03-23T10:30:06Z"}, {"author": "Lorenzo Miniero", "text": ":)<br/>", "time": "2022-03-23T10:30:20Z"}, {"author": "lpardue", "text": "to Cullen's point on multicast and wifi - there is an RFC on that - <a href=\"https://datatracker.ietf.org/doc/rfc9119/\" rel=\"nofollow\">https://datatracker.ietf.org/doc/rfc9119/</a><br/>", "time": "2022-03-23T10:30:36Z"}, {"author": "Brian Trammell", "text": "(and ngl i sit on my balcony with a stopwatch to measure latency differences in the last mile during the Euros and the World Cup)<br/>", "time": "2022-03-23T10:30:51Z"}, {"author": "Craig Taylor", "text": "...and also something similar for LTE<br/>", "time": "2022-03-23T10:30:57Z"}, {"author": "Craig Taylor", "text": "(albeit in a different standards body)<br/>", "time": "2022-03-23T10:31:38Z"}, {"author": "Magnus Westerlund", "text": "How to do multicast over LTE is already existing. Ericsson can sell you a solution. It is just that it doesn't get deployed much. <br/>", "time": "2022-03-23T10:32:18Z"}, {"author": "Jake Holland", "text": "yep.&nbsp;&nbsp;working on it.<br/>", "time": "2022-03-23T10:32:30Z"}, {"author": "Ted Hardie", "text": "Do they roll their own crypto too?<br/>", "time": "2022-03-23T10:32:38Z"}, {"author": "Jake Holland", "text": "I think multicast is mostly a different discussion<br/>", "time": "2022-03-23T10:32:42Z"}, {"author": "Dirk Kutscher", "text": ";-)<br/>", "time": "2022-03-23T10:32:47Z"}, {"author": "Brian Trammell", "text": "yes but it is a very attractive rabbithole<br/>", "time": "2022-03-23T10:32:55Z"}, {"author": "Cullen Jennings", "text": "+1 Chesire <br/>", "time": "2022-03-23T10:33:13Z"}, {"author": "Jake Holland", "text": "i am so far down that rabbithole as a matter of career that i would encourage people who want to discuss it to come discuss it with me in another venue<br/>", "time": "2022-03-23T10:33:26Z"}, {"author": "Brian Trammell", "text": "(i suspect the multicast rabbithole is actually a tree of rabbitholes)<br/>", "time": "2022-03-23T10:33:28Z"}, {"author": "David Schinazi", "text": "@Brian lol<br/>", "time": "2022-03-23T10:33:45Z"}, {"author": "Juliusz Chroboczek", "text": "Heh.<br/>", "time": "2022-03-23T10:33:59Z"}, {"author": "Christian Huitema", "text": "To answer Pete's question: QUIC &amp; head of line blocking<br/>", "time": "2022-03-23T10:34:08Z"}, {"author": "Simon Romano", "text": "I have a general feeling that this (much interesting, btw) BoF has just the wrong name. It is not about media over QUIC. It is rather about finding effective solutions for distributing live real-time (possibly bi-directional) multimedia flows in an effective way. And many such proposals would not even mention QUIC, in my humble opinion.<br/>", "time": "2022-03-23T10:34:11Z"}, {"author": "Dirk Kutscher", "text": "Regarding application-layer multicast, content naming, relays etc, this may be of interest: <a href=\"https://datatracker.ietf.org/doc/html/rfc7933\" rel=\"nofollow\">https://datatracker.ietf.org/doc/html/rfc7933</a><br/>", "time": "2022-03-23T10:34:20Z"}, {"author": "Jake Holland", "text": "for example, at next wednesday's w3c multicast community group meeting: <a href=\"https://www.w3.org/community/multicast/\" rel=\"nofollow\">https://www.w3.org/community/multicast/</a><br/>", "time": "2022-03-23T10:34:21Z"}, {"author": "Luke Curley", "text": "+1 absolutely, I went with QUIC instead of hand-rolling yet another UDP-based protocol because networking is harder than people realize<br/>", "time": "2022-03-23T10:34:22Z"}, {"author": "Magnus Westerlund", "text": "Yes, I think Cullen gave a good answer on multicast. At most enable future extension for multicast can be considered at an architectural level for a solutions.<br/>", "time": "2022-03-23T10:34:27Z"}, {"author": "Barry Leiba", "text": "An applicability statement in MOPS is probably right.<br/>", "time": "2022-03-23T10:34:29Z"}, {"author": "Craig Taylor", "text": "Consolidation/tech-debt<br/>", "time": "2022-03-23T10:34:39Z"}, {"author": "Brian Trammell", "text": "you could encapsulate SCTP in QUIC DATAGRAM?<br/>", "time": "2022-03-23T10:35:02Z"}, {"author": "Pete Resnick", "text": "Whee!!!!<br/>", "time": "2022-03-23T10:35:16Z"}, {"author": "James Gruessing", "text": "Brian it's too early in the morning for those kinds of ideas.<br/>", "time": "2022-03-23T10:35:18Z"}, {"author": "Murray Kucherawy", "text": "application/tech-debt<br/>", "time": "2022-03-23T10:35:30Z"}, {"author": "spencerdawkins", "text": "You can probably attribute the focus on QUIC to deployment issues with anything that doesn't run over TCP and UDP, that we cited when we chartered QUIC. <br/>", "time": "2022-03-23T10:35:37Z"}, {"author": "Brian Trammell", "text": "it's a week and a bit to 1 April so i'm probably rather late<br/>", "time": "2022-03-23T10:35:50Z"}, {"author": "Ted Hardie", "text": "@Brian run SCTP over UDP and use CONNECT-UDP.<br/>", "time": "2022-03-23T10:36:10Z"}, {"author": "Cullen Jennings", "text": "Use Webrtc to negotiate the layering stack :-)<br/>", "time": "2022-03-23T10:36:42Z"}, {"author": "spencerdawkins", "text": "@Ted Hardie - you are making me question the meaning of life ... <br/>", "time": "2022-03-23T10:36:45Z"}, {"author": "Craig Taylor", "text": "Things like: l2/3 devices being able to work with encrypted CIDs for one transport are hugely valuable<br/>", "time": "2022-03-23T10:37:08Z"}, {"author": "Juliusz Chroboczek", "text": "Ted, Cullen, you're onto something.<br/>", "time": "2022-03-23T10:37:26Z"}, {"author": "Jake Holland", "text": "you can never have too many tunnel layers.<br/>", "time": "2022-03-23T10:37:32Z"}, {"author": "Jana Iyengar", "text": "@Ted -- that might be a good way to run WebRTC signaling over QUIC<br/>", "time": "2022-03-23T10:37:49Z"}, {"author": "Luke Curley", "text": "distribution seems like a superset of ingest<br/>", "time": "2022-03-23T10:37:52Z"}, {"author": "Luke Curley", "text": "not 100% but you can absolutely use distribution protocols for ingest<br/>", "time": "2022-03-23T10:38:19Z"}, {"author": "Cullen Jennings", "text": "This chat is just full of gems of wisdom. Still laughing about the webrtc cathedral <br/>", "time": "2022-03-23T10:38:27Z"}, {"author": "Sergio Garcia Murillo", "text": "IMHO distribution use cases are orders of magnitude higher than ingest ones<br/>", "time": "2022-03-23T10:38:40Z"}, {"author": "Sam Hurst", "text": "+1 to James' comments on risking getting ingest bodged in later if we don't consider it now<br/>", "time": "2022-03-23T10:38:43Z"}, {"author": "Alan Frindell", "text": "Going to close the queue in a minute<br/>", "time": "2022-03-23T10:39:41Z"}, {"author": "Pete Resnick", "text": "@Victor: Yes, this should all work well over QUIC, and it will inevitably use QUIC. But that doesn't mean that it should *depend* on QUIC.<br/>", "time": "2022-03-23T10:40:58Z"}, {"author": "Jake Holland", "text": "yes, that is a good point.<br/>", "time": "2022-03-23T10:41:18Z"}, {"author": "Kirill Pugin", "text": "not just delivery :D<br/>", "time": "2022-03-23T10:41:19Z"}, {"author": "Matt Joras", "text": "That's essentially the same thing people said about HTTP/3<br/>", "time": "2022-03-23T10:41:24Z"}, {"author": "lpardue", "text": "TAPS -&gt; MAPS<br/>", "time": "2022-03-23T10:41:34Z"}, {"author": "Kirill Pugin", "text": "every time there is delivery use-case - there is corresponding ingest use-case as well<br/>", "time": "2022-03-23T10:41:37Z"}, {"author": "Victor Vasiliev", "text": "I'm not sure what's the difference between using QUIC and depending on it<br/>", "time": "2022-03-23T10:41:42Z"}, {"author": "Jake Holland", "text": "QAPS?<br/>", "time": "2022-03-23T10:41:47Z"}, {"author": "Matt Joras", "text": "+1 Victor<br/>", "time": "2022-03-23T10:41:50Z"}, {"author": "James Gruessing", "text": "+1 Kirill<br/>", "time": "2022-03-23T10:42:01Z"}, {"author": "Dirk Kutscher", "text": "@Ted, I think you are describing ICN over QUIC.<br/>", "time": "2022-03-23T10:43:01Z"}, {"author": "Juliusz Chroboczek", "text": "ICN?<br/>", "time": "2022-03-23T10:43:20Z"}, {"author": "Pete Resnick", "text": "@Victor: See Luke's comment on TAPS. You want certain capabilities; you don't care what's underneath, and if others have a use case where QUIC isn't underneath, that should be OK.<br/>", "time": "2022-03-23T10:43:26Z"}, {"author": "Dirk Kutscher", "text": "<a href=\"https://datatracker.ietf.org/rg/icnrg/about/\" rel=\"nofollow\">https://datatracker.ietf.org/rg/icnrg/about/</a><br/>", "time": "2022-03-23T10:43:42Z"}, {"author": "Luke Curley", "text": "yeah, Warp would work okay over HTTP/2 WebTransport, but best over HTTP/3 WebTransport<br/>", "time": "2022-03-23T10:43:52Z"}, {"author": "Juliusz Chroboczek", "text": "TY<br/>", "time": "2022-03-23T10:43:56Z"}, {"author": "Jana Iyengar", "text": "@Ted: NMPYN BoF doesn't have the same ring to it<br/>", "time": "2022-03-23T10:44:03Z"}, {"author": "lpardue", "text": "ngwebrtc<br/>", "time": "2022-03-23T10:44:18Z"}, {"author": "Ted Hardie", "text": "@Jana&nbsp;&nbsp;there's a reason I never went into marketing.<br/>", "time": "2022-03-23T10:44:28Z"}, {"author": "Jake Holland", "text": "it warms my soul to have multiple people in the same meting saying multicast out loud and in public without crapping on it.<br/>", "time": "2022-03-23T10:45:21Z"}, {"author": "Matt Joras", "text": "Pete: that is the same thing as \"Why does HTTP/3 depend on QUIC\" -- if someone wants to make a similar HTTP mapping to a different underlying transport that is their business. <br/>Depending on QUIC does have advantages insofar as protocol innovation can be driven by that dependence. Do we really expect that these usecases wouldn't be benefited by new transport semantics and innovation?<br/>", "time": "2022-03-23T10:45:43Z"}, {"author": "Kirill Pugin", "text": "I think when people talk about quality vs. latency tradeoffs is that people talking about risk - if I prefer latency, I would much more cautious about increasing quality<br/>", "time": "2022-03-23T10:46:08Z"}, {"author": "Juliusz Chroboczek", "text": "Could somebody point me at the place where packet scheduling of the QUIC sender is described?<br/>", "time": "2022-03-23T10:46:18Z"}, {"author": "Pete Resnick", "text": "NB: Nobody (especially me) has said *not* to do this over QUIC.<br/>", "time": "2022-03-23T10:47:03Z"}, {"author": "Jody Beck", "text": "+1 Matt<br/>", "time": "2022-03-23T10:47:04Z"}, {"author": "Jana Iyengar", "text": "@Juliusz -- There isn't one, because that is application and use-case dependent<br/>", "time": "2022-03-23T10:47:07Z"}, {"author": "Sergio Garcia Murillo", "text": "+1<br/>", "time": "2022-03-23T10:47:13Z"}, {"author": "James Gruessing", "text": "Requirements can only really come when we have a vaguely agreed scope of use cases.<br/>", "time": "2022-03-23T10:47:21Z"}, {"author": "Simon Romano", "text": "+1<br/>", "time": "2022-03-23T10:47:22Z"}, {"author": "Barry Leiba", "text": "Matt: I think the point is whether we need a new media protocol, or whether we're just talking about how to run existing protocols over QUIC to make best advantage.<br/>", "time": "2022-03-23T10:47:48Z"}, {"author": "Barry Leiba", "text": "I think it's the latter.<br/>", "time": "2022-03-23T10:47:57Z"}, {"author": "lpardue", "text": "@juliusz doe <a href=\"https://www.rfc-editor.org/rfc/rfc9000.html#section-13\" rel=\"nofollow\">https://www.rfc-editor.org/rfc/rfc9000.html#section-13</a> fit your ask?<br/>", "time": "2022-03-23T10:48:12Z"}, {"author": "David Schinazi", "text": "We need to write an IETFoverQUIC RFC<br/>", "time": "2022-03-23T10:48:19Z"}, {"author": "Sergio Garcia Murillo", "text": "+1 to cullen<br/>", "time": "2022-03-23T10:48:27Z"}, {"author": "Christian Huitema", "text": "@Juliusz; see <a href=\"https://www.researchgate.net/publication/342783300_Same_Standards_Different_Decisions_A_Study_of_QUIC_and_HTTP3_Implementation_Diversity\" rel=\"nofollow\">https://www.researchgate.net/publication/342783300_Same_Standards_Different_Decisions_A_Study_of_QUIC_and_HTTP3_Implementation_Diversity</a><br/>", "time": "2022-03-23T10:48:36Z"}, {"author": "Alan Frindell", "text": "justin: mariners!!<br/>", "time": "2022-03-23T10:48:41Z"}, {"author": "Matt Joras", "text": "Barry: considering we have proposals for _new protocol_ proposals, why would it be the latter? Clearly there is interest in new protocols utilizing QUIC, not just mapping existing protocols to QUIC.<br/>", "time": "2022-03-23T10:49:03Z"}, {"author": "Jana Iyengar", "text": "@Barry -- not quite ... if that was the case, we would be talking about WebRTC over QUIC<br/>", "time": "2022-03-23T10:49:17Z"}, {"author": "Juliusz Chroboczek", "text": "Jana, Christian, thanks to both.&nbsp;&nbsp;Section 2.3 of RFC 9000 is a big disappointment to me.<br/>", "time": "2022-03-23T10:49:23Z"}, {"author": "Pete Resnick", "text": "@David: One sentence RFC that says, \"Whatever protocol you create, you SHOULD run it over QUIC.\"<br/>", "time": "2022-03-23T10:49:33Z"}, {"author": "Jake Holland", "text": "yep.&nbsp;&nbsp;you can never have too many tunneling layers.<br/>", "time": "2022-03-23T10:50:01Z"}, {"author": "Simon Romano", "text": ":-))<br/>", "time": "2022-03-23T10:50:01Z"}, {"author": "David Schinazi", "text": "IPvQUIC?<br/>", "time": "2022-03-23T10:50:07Z"}, {"author": "Jake Holland", "text": "(that is called datagrams)<br/>", "time": "2022-03-23T10:50:21Z"}, {"author": "Pete Resnick", "text": "BGP over QUIC?<br/>", "time": "2022-03-23T10:50:27Z"}, {"author": "Cullen Jennings", "text": "sorry - I missed the name of what protcol he said <br/>", "time": "2022-03-23T10:50:35Z"}, {"author": "Kirill Pugin", "text": "SRT<br/>", "time": "2022-03-23T10:50:42Z"}, {"author": "Juliusz Chroboczek", "text": "SRT<br/>", "time": "2022-03-23T10:50:43Z"}, {"author": "Cullen Jennings", "text": "thanks<br/>", "time": "2022-03-23T10:50:46Z"}, {"author": "Christian Huitema", "text": "@Pete that would make more sense than BGP over TCP-AO<br/>", "time": "2022-03-23T10:50:50Z"}, {"author": "Pete Resnick", "text": ":-D<br/>", "time": "2022-03-23T10:51:00Z"}, {"author": "lpardue", "text": "there are at least two I-Ds for BGP over QUIC<br/>", "time": "2022-03-23T10:51:07Z"}, {"author": "Pete Resnick", "text": "MPLS over QUIC<br/>", "time": "2022-03-23T10:51:21Z"}, {"author": "Luke Curley", "text": "+1 there should be a tight binding between the encoding and transport layer<br/>", "time": "2022-03-23T10:51:23Z"}, {"author": "lpardue", "text": "e.g. <a href=\"https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic-stream/\" rel=\"nofollow\">https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic-stream/</a><br/>", "time": "2022-03-23T10:51:25Z"}, {"author": "Jana Iyengar", "text": "@Juliuz -- that is very deliberate. The application decides how to prioritize, not the transport. See HTTP/3 priorities discussion for a scheduling discussion on how HTTP can schedule.<br/>", "time": "2022-03-23T10:51:29Z"}, {"author": "spencerdawkins", "text": "@lpardue, why so few?<br/>", "time": "2022-03-23T10:51:32Z"}, {"author": "lpardue", "text": ":D<br/>", "time": "2022-03-23T10:51:51Z"}, {"author": "Kirill Pugin", "text": "mic: +1<br/>", "time": "2022-03-23T10:52:10Z"}, {"author": "Sergio Garcia Murillo", "text": "+1 to hta<br/>", "time": "2022-03-23T10:52:36Z"}, {"author": "Luke Curley", "text": "modifying the encoder bitrate, dropping frames, and queueing data are all forms of congestion control IMO<br/>", "time": "2022-03-23T10:52:37Z"}, {"author": "Simon Romano", "text": "+1 to what Harald is saying.<br/>", "time": "2022-03-23T10:52:49Z"}, {"author": "Lars Eggert", "text": "so we did try with rmcat. it didn't work well. open to trying again, but what has changed?<br/>", "time": "2022-03-23T10:52:54Z"}, {"author": "David Schinazi", "text": "IP router AQM is a form of congestion control<br/>", "time": "2022-03-23T10:52:55Z"}, {"author": "Matt Joras", "text": "To add to what Jana said, the application decides prioritization, the transport should provide a way to fulfill that prioritization.<br/>", "time": "2022-03-23T10:52:58Z"}, {"author": "Luke Curley", "text": "traditional TCP congestion control only focuses on queueing data, but live media is ore than that<br/>", "time": "2022-03-23T10:53:00Z"}, {"author": "Juliusz Chroboczek", "text": "Jana, I'm surely missing a piece here.&nbsp;&nbsp;If the application can communicate priorities to QUIC, shouldn't QUIC make it explicit what scheduling policies the application will get from the priorities it chooses?<br/>", "time": "2022-03-23T10:53:00Z"}, {"author": "Dawei Fan", "text": "+1 to what Harald is saying.<br/>", "time": "2022-03-23T10:53:06Z"}, {"author": "Piers O'Hanlon", "text": "+1 Harald<br/>", "time": "2022-03-23T10:53:27Z"}, {"author": "David Schinazi", "text": "@Juliusz that's more of an API question than a protocol question. RFC 9000 focused on the protocol but not APIs<br/>", "time": "2022-03-23T10:53:31Z"}, {"author": "Jake Holland", "text": "the claim that there are groups that know congestion control (very well) better than other groups that know media (somewhat well) is a bit sus.&nbsp;&nbsp;There's a reason iccrg is still a rg, *nobody* knows it all that well.<br/>", "time": "2022-03-23T10:54:12Z"}, {"author": "Pete Resnick", "text": "I'm really interested in the ones saying \"no\". What do they mean?<br/>", "time": "2022-03-23T10:54:16Z"}, {"author": "Jake Holland", "text": "but yes, +1 harald, that merger is at the core of what ietf should be addressing.<br/>", "time": "2022-03-23T10:54:33Z"}, {"author": "Anna Brunstrom", "text": "Re the API. There will be a talk on a QUIC mapping for TAPS in the TAPS session after lunch today.<br/>", "time": "2022-03-23T10:54:37Z"}, {"author": "lpardue", "text": "in time we (QUIC) might consider more text on prioritization and scheduling. But trying to answer that in RFC 9000 would have been difficult, time consuming and most likely yielded an incorrect answer<br/>", "time": "2022-03-23T10:54:55Z"}, {"author": "Juliusz Chroboczek", "text": "It would be nice to be able to abstain.<br/>", "time": "2022-03-23T10:55:05Z"}, {"author": "Jana Iyengar", "text": "Don't know, Cullen<br/>", "time": "2022-03-23T10:55:07Z"}, {"author": "Piers O'Hanlon", "text": "I think it would be useful to expose more info from the Congestion control state to application level.<br/>", "time": "2022-03-23T10:55:14Z"}, {"author": "Jana Iyengar", "text": "Hold up a newspaper Cullen<br/>", "time": "2022-03-23T10:55:15Z"}, {"author": "Christian Huitema", "text": "Live? The IETF? Aren't all comments at the mike pre-recorded years ago and then replayed?<br/>", "time": "2022-03-23T10:56:01Z"}, {"author": "hta", "text": "people can agree that there is a case that isn't met without agreeing on what the unmet use case is....\u00a8<br/>", "time": "2022-03-23T10:56:01Z"}, {"author": "lpardue", "text": "the webtransport (in IETF and W3C) discussion about prioritization of streams vs datagram is a great example of how hard saying anything definitive is<br/>", "time": "2022-03-23T10:56:18Z"}, {"author": "Jana Iyengar", "text": "@Christian -- I believe that comment of yours is from 14 years ago.<br/>", "time": "2022-03-23T10:56:43Z"}, {"author": "hta", "text": "on the 3rd question I am not raising a hand, because I believe the question is not well formed.<br/>", "time": "2022-03-23T10:56:53Z"}, {"author": "Justin Uberti", "text": "likewise<br/>", "time": "2022-03-23T10:57:14Z"}, {"author": "Simon Romano", "text": "Same here<br/>", "time": "2022-03-23T10:57:35Z"}, {"author": "Sergio Garcia Murillo", "text": "same<br/>", "time": "2022-03-23T10:57:44Z"}, {"author": "Eric Kinnear", "text": "Is there a Live Media Streaming use case that is not met today?<br/>raise hand<br/>55<br/>do not raise hand<br/>13<br/>participants<br/>68<br/>", "time": "2022-03-23T10:57:54Z"}, {"author": "David Schinazi", "text": "I need to see requirements before I can answer 3<br/>", "time": "2022-03-23T10:57:57Z"}, {"author": "Eric Kinnear", "text": "Is there a Media Ingestion use case that is not met today?<br/>raise hand<br/>53<br/>do not raise hand<br/>7<br/>participants<br/>60<br/>", "time": "2022-03-23T10:58:14Z"}, {"author": "Alan Frindell", "text": "is ted's rephrasing sufficiiently clear<br/>", "time": "2022-03-23T10:58:24Z"}, {"author": "Alan Frindell", "text": "?<br/>", "time": "2022-03-23T10:58:27Z"}, {"author": "Justin Uberti", "text": "works for me<br/>", "time": "2022-03-23T10:59:06Z"}, {"author": "Pete Resnick", "text": "Yeah, I'm in the \"no clue\" category.<br/>", "time": "2022-03-23T10:59:27Z"}, {"author": "Sergio Garcia Murillo", "text": "re, the ones not raising hands. I don't think the use cases can't be met today with current standards. But I don't think that it prevents to create a new protocol for leveraging QUIC.<br/>", "time": "2022-03-23T10:59:47Z"}, {"author": "hta", "text": "since the previous polls did not identify the One And Only Use Case (I don't think there is one), \"sets of use cases\" is right.<br/>", "time": "2022-03-23T10:59:48Z"}, {"author": "Eric Kinnear", "text": "Should work on these two sets of use cases be done together?<br/>raise hand<br/>50<br/>do not raise hand<br/>8<br/>participants<br/>58<br/>", "time": "2022-03-23T10:59:56Z"}, {"author": "lpardue", "text": "that you chairs and all participants, this was fun<br/>", "time": "2022-03-23T11:00:30Z"}, {"author": "spencerdawkins", "text": "I sent an email to the MOQ list with Subject \"Can the IETF do more than one thing after the MOQ BOF?\" - it's my theory about how to move forward. Other people may have other thoughts, of course. :-D<br/>", "time": "2022-03-23T11:00:43Z"}, {"author": "Simon Romano", "text": "Loved this session. Thanks!<br/>", "time": "2022-03-23T11:00:51Z"}, {"author": "Jake Holland", "text": "this went way better than the last moq side meeting.<br/>", "time": "2022-03-23T11:00:51Z"}, {"author": "Chris Lemmons", "text": "Yes, many thanks to the chairs!<br/>", "time": "2022-03-23T11:01:02Z"}, {"author": "Kirill Pugin", "text": "lol<br/>", "time": "2022-03-23T11:01:03Z"}, {"author": "Matt Joras", "text": "100% fewer spreadsheets<br/>", "time": "2022-03-23T11:01:04Z"}, {"author": "Murray Kucherawy", "text": "Yeah, thanks, well done.<br/>", "time": "2022-03-23T11:01:08Z"}, {"author": "hta", "text": "good to see focus on \"what isthe problem to be solved\".<br/>", "time": "2022-03-23T11:01:13Z"}, {"author": "Kirill Pugin", "text": "thanks everyone!<br/>", "time": "2022-03-23T11:01:18Z"}, {"author": "Juliusz Chroboczek", "text": "Thanks!<br/>", "time": "2022-03-23T11:01:20Z"}, {"author": "Jana Iyengar", "text": "Spreadsheets FTW! Better than slides sometimes<br/>", "time": "2022-03-23T11:01:22Z"}, {"author": "James Gruessing", "text": "Thanks!<br/>", "time": "2022-03-23T11:01:24Z"}, {"author": "Sam Hurst", "text": "Thanks very much - very interesting session<br/>", "time": "2022-03-23T11:01:24Z"}, {"author": "Varun Singh", "text": "thanks!<br/>", "time": "2022-03-23T11:01:35Z"}, {"author": "spencerdawkins", "text": "@Jake - I think that side meeting had about the same number of participants, and I certainly would have benefitted from two chairs!<br/>", "time": "2022-03-23T11:01:48Z"}]