I\u2019m on my way
", "time": "2023-03-29T04:03:04Z"}, {"author": "David Schinazi", "text": "Walking back from lunch
", "time": "2023-03-29T04:03:17Z"}, {"author": "David Schinazi", "text": "meetecho can we have the camera look at the speaker please?
", "time": "2023-03-29T04:08:52Z"}, {"author": "David Schinazi", "text": "Perfect, thanks!
", "time": "2023-03-29T04:09:12Z"}, {"author": "Lucas Pardue", "text": "yay more borwsers
", "time": "2023-03-29T04:13:47Z"}, {"author": "David Schinazi", "text": "No no Bowser is something else Lucas
", "time": "2023-03-29T04:14:54Z"}, {"author": "Lucas Pardue", "text": "waaaa
", "time": "2023-03-29T04:15:33Z"}, {"author": "Alan Frindell", "text": "I think MT said FF sends both the draft-08 codepoint and rfc?
", "time": "2023-03-29T04:17:39Z"}, {"author": "Lucas Pardue", "text": "Two of the versions are format compatible
", "time": "2023-03-29T04:18:27Z"}, {"author": "Lucas Pardue", "text": "just sandwiched in between is an incompatible one :(
", "time": "2023-03-29T04:18:47Z"}, {"author": "Lucas Pardue", "text": "an example is memory commitment of N streams multiplied by the connection-wide initial flow control limit
", "time": "2023-03-29T04:27:37Z"}, {"author": "Marten Seemann", "text": "DoS-ing a browser is trivially easy
", "time": "2023-03-29T04:30:26Z"}, {"author": "Kazuho Oku", "text": "What does this \"limit\" actually mean?
\nI could very well be incorrect, but as WebTransport streams are mapped to HTTP streams, does WebTransport requesting 1000 streams to be open mean that the server has to accept up to 1000 HTTP requests at once as well?
Or are WebTransport stacks restrict number of HTTP requests that would be initiated on the connection that is being shared?
", "time": "2023-03-29T04:32:23Z"}, {"author": "Marten Seemann", "text": "This is about the other direction iiuc
", "time": "2023-03-29T04:32:27Z"}, {"author": "Kazuho Oku", "text": "Yes in sense that it is an API question.
", "time": "2023-03-29T04:33:15Z"}, {"author": "Harald Alvestrand", "text": "my favorite limit example is actually number of RTCPeerConnections. We discovered that stuff started going really sideways if people created 1000 of them, so we put in a limt of 500. There were people bitterly complaining that we ruined their applicaiton.
", "time": "2023-03-29T04:33:50Z"}, {"author": "Alan Frindell", "text": "I don't think a single order for all datagrams is what you want.
", "time": "2023-03-29T04:35:35Z"}, {"author": "Harald Alvestrand", "text": "we still don' t have API to tell apps what number of RTCPeerConnections they can create.
", "time": "2023-03-29T04:35:42Z"}, {"author": "Marten Seemann", "text": "Here's the point I wanted to make:
\nOn the browser side, the limit is not interesting in the sense of a DoS defense. For a server, it's trivial to run a DoS against a browser.
\nWhat we _should_ be thinking about is the cases where the limit is actually useful in preventing the browser from getting overwhelmed in a non-attack scenario (example: flow control when the client is just slow consuming the data).
+1
", "time": "2023-03-29T04:36:23Z"}, {"author": "David Schinazi", "text": "Thanks Marten, can you say this on GitHub? https://github.com/w3c/webtransport/issues/446
", "time": "2023-03-29T04:38:01Z"}, {"author": "Alan Frindell", "text": "Does a client also send WT_MAX_SESSIONS?
", "time": "2023-03-29T04:39:00Z"}, {"author": "Marten Seemann", "text": "Done
", "time": "2023-03-29T04:39:15Z"}, {"author": "Alan Frindell", "text": "Do we want to reset the h2 stream, or CLOSE_WEBTRANSPORT_SESSION + FIN ?
", "time": "2023-03-29T04:40:21Z"}, {"author": "Kazuho Oku", "text": "@Alan Frindell +1, we might want to open as many streams from the client as well. And the question is if we have messages for that as well as what the security implication of that is.
", "time": "2023-03-29T04:41:45Z"}, {"author": "Randell Jesup", "text": "Not raising my hand, but there didn't have to be an issue in DataChannels with the number of channels; Firefox has an implementation where we could easily support 64K channels if needed. If the application needs N streams, you either can support the application (have the memory), or you can't. Setting a lower limit artificially can make certain applications either unimplementable, or will warp their design to fit into a smaller limit. Other applications will simply not realize that they might go over the limit in some edge case, and fall down badly when they do (for example, when 20 people join a video chat) -- while almost certainly the application is not limited by memory from having N streams active
", "time": "2023-03-29T04:42:43Z"}, {"author": "Peter Thatcher", "text": "Related to a slide way back: I just made a PR for adding estimated send rate to the web API: https://github.com/w3c/webtransport/pull/494
", "time": "2023-03-29T04:43:31Z"}, {"author": "Kazuho Oku", "text": "I totally agree with that for a connection dedicated to WebTransport. But what if the connection is shared with other protocols, e.g., HTTP. Is it a good idea to set QUIC-level concurrency to max of the two protocols?
", "time": "2023-03-29T04:44:17Z"}, {"author": "Marten Seemann", "text": "We have a very similar problem in WebTransport/H3. This problem occurs because we're running multiple sessions on top of a single connection (be it H2 or H3) without proper resource accounting.
", "time": "2023-03-29T04:49:06Z"}, {"author": "Randell Jesup", "text": "The philosophy used in the Amiga OS, ages ago when ram was a LOT smaller was don't ever set artificial limits on things; have them be constrained only by memory and peformance; use dynamic lists (or dynamic tables/arrays) for everything, never static. Maybe there's a good reason to limit things; if so let's specify it, and thus far I haven't seen memory as a limit. Fixed limits may simply drive applications that need more to implement their own multiplexing within streams
", "time": "2023-03-29T04:49:20Z"}, {"author": "Lucas Pardue", "text": "I was going to ask at the mic, did you consider a new frame other than SETTINGS?
", "time": "2023-03-29T04:51:23Z"}, {"author": "Jonathan Lennox", "text": "Would it be ok to require the extra RTT in the initial release of WT/H2, and then it can have a SETTINGS-based optimization in the future if that's a pain point?
", "time": "2023-03-29T04:51:37Z"}, {"author": "Randell Jesup", "text": "On a different topic -- if you want to try WebTransport in Firefox, make sure it's a 3/28 or later Nightly; 3/28 has a bugfix where some extensions would cause WebTransport not to connect. 3/29 Nightly will have it prefed on by default
", "time": "2023-03-29T04:51:40Z"}, {"author": "Alan Frindell", "text": "Bernard - can you clarify the problems you think aren't solved by the draft
", "time": "2023-03-29T05:00:20Z"}, {"author": "Lucas Pardue", "text": "maybe we should wrap up all these required extensions into a QUIC version :P
", "time": "2023-03-29T05:00:42Z"}, {"author": "Lucas Pardue", "text": "agree with Ted
", "time": "2023-03-29T05:03:58Z"}, {"author": "Alan Frindell", "text": "Having to wait to parse the stream type before resetting it seems like another reason not to overlap H3
", "time": "2023-03-29T05:06:40Z"}, {"author": "Ted Hardie", "text": "IANA has seen worse, for those worrying that it is ugly.
", "time": "2023-03-29T05:08:03Z"}, {"author": "Lucas Pardue", "text": "I described it as \"cgroups for QUIC\" to someone earlier in the week
", "time": "2023-03-29T05:14:03Z"}, {"author": "Alex Chernyakhovsky", "text": "now we need namespaces for QUIC and then we can have docker for quic
", "time": "2023-03-29T05:14:22Z"}, {"author": "Lucas Pardue", "text": "i like it
", "time": "2023-03-29T05:14:56Z"}, {"author": "Alan Frindell", "text": "I'm also a flow control enthus
", "time": "2023-03-29T05:19:58Z"}, {"author": "Lucas Pardue", "text": "to clarify I agree it can be useful
", "time": "2023-03-29T05:22:05Z"}, {"author": "Eric Kinnear", "text": "If we wanted to do this in QUIC land, it's essentially another version of the QUIC \"stream group\" proposals
", "time": "2023-03-29T05:22:41Z"}, {"author": "Lucas Pardue", "text": "yep ^^
", "time": "2023-03-29T05:22:50Z"}, {"author": "Zaheduzzaman Sarker", "text": "On the flow control issue, I agree with MT about not dropping the ball ... but how do we capture this if there is not solution proposed till IETF117?
", "time": "2023-03-29T05:26:36Z"}, {"author": "Lucas Pardue", "text": "CONNECT doesn't say anything specific about redirects either https://www.rfc-editor.org/rfc/rfc9110.html#name-connect
", "time": "2023-03-29T05:32:46Z"}, {"author": "Alex Chernyakhovsky", "text": "Thanks for confirming that @Lucas Pardue I was looking too and also couldn't find it and wasn't sure if I was just holding the manual wrong
", "time": "2023-03-29T05:33:12Z"}, {"author": "Lucas Pardue", "text": "I mean, I await mnot to hit me over the head with the manual, but AFAICT MASQUE didn't do so bad
", "time": "2023-03-29T05:34:09Z"}, {"author": "Kazuho Oku", "text": "The question is if clients are supposed to automatically follow the redirects, correct? That's not required by HTTP IIUC, it's up to each application.
", "time": "2023-03-29T05:35:31Z"}, {"author": "Alex Chernyakhovsky", "text": "Yeah, and masque provides good precedent here
", "time": "2023-03-29T05:37:19Z"}, {"author": "Jonathan Lennox", "text": "An H3/WT redirect could possibly end up on H2/WT, which seems like it'd be very hard for a stack to handle automatically.
", "time": "2023-03-29T05:37:31Z"}, {"author": "Kazuho Oku", "text": "Ultimate precedence is CONNECT method, it does not have a URI and it's impossible to redirect IIUC.
", "time": "2023-03-29T05:38:33Z"}, {"author": "Lucas Pardue", "text": "lol CONNECT says \"Any response other than a successful response indicates that the tunnel has not yet been formed.\" while CONNECT UDP says \"If any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request.\" so /shrug
", "time": "2023-03-29T05:38:58Z"}, {"author": "Kazuho Oku", "text": "so CONNECT considers 3xx as 1xx?
", "time": "2023-03-29T05:39:39Z"}, {"author": "Lucas Pardue", "text": "unclear to me
", "time": "2023-03-29T05:39:48Z"}, {"author": "Kazuho Oku", "text": "RFC 7231 says \"Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains governed by HTTP\" which is clear IMO. We accidentally made it unclear in 9110.
", "time": "2023-03-29T05:42:13Z"}, {"author": "Lucas Pardue", "text": "lets hit mnot over the head with the manual!
", "time": "2023-03-29T05:42:47Z"}, {"author": "Luke Curley", "text": "didn't realize the difference between 3&4, both work but 4 is slightly better
", "time": "2023-03-29T05:51:20Z"}, {"author": "Ted Hardie", "text": "I think 4 is a sensible option for an implementation, but the reality is 1 if you're at the app layer; you get what you get.
", "time": "2023-03-29T05:52:01Z"}, {"author": "Luke Curley", "text": "just to summarize: since pooling is transparent to the application, the prioritization behavior shouldn't change if pooling is supported/used
", "time": "2023-03-29T05:53:24Z"}, {"author": "Luke Curley", "text": "it seems awful to support pooling but not round-robin between sessions
", "time": "2023-03-29T05:54:41Z"}, {"author": "Alan Frindell", "text": "We're still hashing things out in moq, but one idea is something like all the tracks of a video might be a webtransport session, but maybe you're pulling more than one at a time, and some might be more important than others.
", "time": "2023-03-29T05:55:16Z"}, {"author": "Alan Frindell", "text": "eg: our FB app is playing one video and prefetching another. Sequential priority between those might be what you want. But you also want to prioritize audio and video within each video
", "time": "2023-03-29T05:55:59Z"}, {"author": "Alan Frindell", "text": "Or maybe have Priority extension for weighting one incremental session vs another.
", "time": "2023-03-29T05:57:08Z"}, {"author": "Luke Curley", "text": "IMO you can combine the prioritization domains only if two sessions (applications) agree to share
", "time": "2023-03-29T05:57:29Z"}, {"author": "Luke Curley", "text": "but I dunno that seems weird to signal
", "time": "2023-03-29T05:57:55Z"}, {"author": "Alan Frindell", "text": "yeah I could pull N videos over one session, but the priority is easier to express hierarchically
", "time": "2023-03-29T05:58:30Z"}, {"author": "Francesca Palombini", "text": "Thank you all! Thanks David and Bernard
", "time": "2023-03-29T06:00:05Z"}]