[{"author": "Juliusz Chroboczek", "text": "

Native English speakers \u201ccommunicating clearly, including speaking slowly
\nand limiting the use of slang\u201d

", "time": "2023-07-27T20:09:21Z"}, {"author": "Juliusz Chroboczek", "text": "

I'm in favour :-)

", "time": "2023-07-27T20:09:27Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

So devious.

", "time": "2023-07-27T20:11:57Z"}, {"author": "Luke Curley", "text": "

https://docs.rs/webtransport-quinn/latest/webtransport_quinn/

", "time": "2023-07-27T20:13:06Z"}, {"author": "Luke Curley", "text": "

oops there's an ietf-116 channel

", "time": "2023-07-27T20:13:36Z"}, {"author": "Luke Curley", "text": "

https://docs.rs/webtransport-quinn/latest/webtransport_quinn/ if anybody is interested

", "time": "2023-07-27T20:14:08Z"}, {"author": "Kenichi Ishibashi", "text": "

Luke, I sent a PR to fix your server sending :protocol

", "time": "2023-07-27T20:15:21Z"}, {"author": "Cullen Jennings", "text": "

Congrats to FF

", "time": "2023-07-27T20:18:34Z"}, {"author": "Alan Frindell", "text": "

Which draft version(s) does FF support?

", "time": "2023-07-27T20:18:55Z"}, {"author": "Juliusz Chroboczek", "text": "

Yeah, it's pretty cool. Is there a webpage that summarises the server-side implementations?

", "time": "2023-07-27T20:19:08Z"}, {"author": "Juliusz Chroboczek", "text": "

Or at least one server-side implementation that people recommend.

", "time": "2023-07-27T20:20:53Z"}, {"author": "Sauli Kiviranta", "text": "

+1 for #2 time window when retransmission is high priority when the data is needed for interactive purposes but the falls down to lower priority when its just about archival for other post session use-cases

", "time": "2023-07-27T20:37:10Z"}, {"author": "Juliusz Chroboczek", "text": "

Listen to Cullen!

", "time": "2023-07-27T20:37:55Z"}, {"author": "Alan Frindell", "text": "

The flow control argument is compelling

", "time": "2023-07-27T20:38:45Z"}, {"author": "Juliusz Chroboczek", "text": "

Disagree with the last speaker, he's assuming the link is uncongested.

", "time": "2023-07-27T20:38:53Z"}, {"author": "Alan Frindell", "text": "

Starving a rtx indefinitely is potentially risky, the application can create a deadlock

", "time": "2023-07-27T20:40:22Z"}, {"author": "Juliusz Chroboczek", "text": "

Point taken.

", "time": "2023-07-27T20:40:48Z"}, {"author": "Ali Begen", "text": "

Exactly!

", "time": "2023-07-27T20:40:51Z"}, {"author": "Dragana Damjanovic", "text": "

agree with Alan.

", "time": "2023-07-27T20:41:28Z"}, {"author": "David Schinazi", "text": "

More seriously, where are these datagram unenthusiasts?

", "time": "2023-07-27T20:41:29Z"}, {"author": "David Schinazi", "text": "

I'd love to understand their concerns

", "time": "2023-07-27T20:41:43Z"}, {"author": "Alan Frindell", "text": "

I'm a stream enthusiast

", "time": "2023-07-27T20:41:52Z"}, {"author": "Juliusz Chroboczek", "text": "

You can be enthusiastic about both.

", "time": "2023-07-27T20:42:16Z"}, {"author": "David Schinazi", "text": "

WWHTTP2D?

", "time": "2023-07-27T20:45:13Z"}, {"author": "Juliusz Chroboczek", "text": "

Why would SRTP need the keyin material, rather than leveraging the authentified WebTransport channel in order to perform an ECDH exchange?

", "time": "2023-07-27T20:58:17Z"}, {"author": "Juliusz Chroboczek", "text": "

(or your favourite post-quantum key exchange.)

", "time": "2023-07-27T20:58:42Z"}, {"author": "Jonathan Lennox", "text": "

Because the WebTransport channel has already done the ECDH and/or PQ key exchange, so it's a lot cheaper to do a key derivation than a whole new assymetric crypto?

", "time": "2023-07-27T20:59:51Z"}, {"author": "Juliusz Chroboczek", "text": "

Ah, okay, I see the tradeoff. Still not convinced it's worth adding an API in order to shave off a few dozen microseconds of CPU time, but I see your point.

", "time": "2023-07-27T21:01:06Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

max(max(client), max(server))? That doesn't seem right to me.

", "time": "2023-07-27T21:01:10Z"}, {"author": "Nils Ohlmeier", "text": "

But the existing API's in browsers don't allow you to set any keys. So it's not like an web app could actually use the keys.

", "time": "2023-07-27T21:01:33Z"}, {"author": "Juliusz Chroboczek", "text": "

I've only just realised that Cullen and Fluffy are the same person :-)

", "time": "2023-07-27T21:09:59Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

max(client \u2229 server) makes so much more sense. Yay.

", "time": "2023-07-27T21:10:39Z"}, {"author": "Alan Frindell", "text": "

Does MAX_WT_SESSIONS > 1 imply F/C support then?

", "time": "2023-07-27T21:22:16Z"}, {"author": "Murray Kucherawy", "text": "

@Cullen: What's Juliusz talking about?

", "time": "2023-07-27T21:22:22Z"}, {"author": "Spencer Dawkins", "text": "

@Bernard Aboba - Bernard, should I be worried about how this discussion maps into Roc?

", "time": "2023-07-27T21:29:33Z"}, {"author": "Martin Thomson", "text": "

I don't know if Dragana remembers better than I, but I believe that we had to do extra work to turn pooling off. That said, we were aware of a few of these issues (flow control in particular) that we didn't want to think about right then.

", "time": "2023-07-27T21:34:16Z"}, {"author": "Martin Thomson", "text": "

stream group = connection

", "time": "2023-07-27T21:34:50Z"}, {"author": "Juliusz Chroboczek", "text": "

I'm a little confused. Are people expecting that a set of dedicated connections behaves exactly the same as a multiplexed connection? I don't think our CC technlogy is mature enough to ensure that.

", "time": "2023-07-27T21:36:44Z"}, {"author": "Martin Thomson", "text": "

two concurrent connections only equalize congestion windows if they are equally busy

", "time": "2023-07-27T21:36:44Z"}, {"author": "David Schinazi", "text": "

If you toss priorities into the mix it gets even more fun

", "time": "2023-07-27T21:38:35Z"}, {"author": "Juliusz Chroboczek", "text": "

FWIW, the WebRTC API gives the JavaScript programmer explicit control over pooling.

", "time": "2023-07-27T21:39:00Z"}, {"author": "Martin Thomson", "text": "

Mo might have misinterpreted me. I want to be lazy and not implement the optionality. There is a good chance that we'll also be lazy and also set a very large limit, but we'll see.

", "time": "2023-07-27T21:40:19Z"}, {"author": "Jonathan Lennox", "text": "

To echo back to an earlier comment, the discussion of pooled sessions makes me wonder what happens if two pooled sessions both export keys...

", "time": "2023-07-27T21:42:47Z"}, {"author": "Kazuho Oku", "text": "

I think this can be an optional feature of webtrans.
\nEach endpoint can reject pooling, then the question is what is the point of requiring the peer to do the \"receive side of\" flow control, even when they might be rejecting pooling?

", "time": "2023-07-27T21:42:51Z"}, {"author": "Luke Curley", "text": "

Kenichi Ishibashi said:

\n
\n

Luke, I sent a PR to fix your server sending :protocol

\n
\n

heh thanks

", "time": "2023-07-27T21:52:40Z"}]