WEBVTT

00:00.000 --> 00:09.880
So the room is full today, thank you for coming so we are going to start so I'd like

00:09.880 --> 00:15.000
to welcome one of my colleague, Max from Berlin, who is going to talk about WebTonSpof.

00:15.000 --> 00:21.520
Thank you very much, thanks for so many people showing up here, it seems to be a very

00:21.520 --> 00:26.440
popular topic, appreciate all your attention, it's wonderful.

00:26.440 --> 00:34.120
Okay, I want to give an introduction to WebTonSpof and I want to post this as a question

00:34.120 --> 00:41.040
whether it's going to be the next WebSockets in the Web.

00:41.040 --> 00:46.800
I'm Max from a software developer at Mozilla, I'm working on Firefox's networking stack,

00:46.800 --> 00:51.920
and within the Firefox networking stack I mostly focus on HTTP theory and quick, and

00:51.920 --> 00:57.000
we'll have plenty of talking points here about HTTP theory and quick, I'd do it you all

00:57.000 --> 01:02.360
in with a phrase a WebTonSpof, we're really what I'm going to talk about here is quick

01:02.360 --> 01:07.520
in HTTP 3 and all the properties that we can then pass up to the higher levels.

01:07.520 --> 01:13.640
And very much a level of transport person, so be with me, I love it here.

01:13.640 --> 01:19.080
If you want to learn more about me, this is my home page, obviously reach out to me, I'm going

01:19.080 --> 01:22.440
to be here, I don't think I'm going to take the whole time, so I'm going to be here

01:22.440 --> 01:26.280
for questions in the room, I'm also going to do questions afterwards outside, so if you

01:26.280 --> 01:33.960
would be free to find me there, or send me an email or anything, but like, okay, before

01:33.960 --> 01:39.440
we can talk about the next WebSockets, let's first talk about WebSockets itself, and

01:39.440 --> 01:45.680
quick show of hands, who here has used WebSockets, all right, let's need one, who has programmed

01:45.680 --> 01:50.760
against WebSockets as an operating, some kind of WebSocket like service, okay, wonderful,

01:50.760 --> 01:58.160
okay, three years heard about WebTransport, who is using WebTransport?

01:58.160 --> 02:12.040
Wow, brave soul, all right, and so, back to WebSockets, it's a very established Web API today

02:12.040 --> 02:17.760
that as a Web application gives you a single reliable, bi-directional, ordered by stream

02:17.760 --> 02:22.040
from the client to the server, as in from the web context in the browser, you can then communicate

02:22.040 --> 02:27.480
to the server, and basically can do with that or whatever you want, started off on

02:27.480 --> 02:37.920
HP1, in December 2011 that was standardized as was a tier RC6455, so quite early, and

02:37.920 --> 02:43.440
what it gives you on HP1, HP1 is built on top of TCP, we'll go a little bit into that,

02:43.440 --> 02:49.640
it gives you a single session, so it upgrades the whole TCP connection to a WebSocket stream.

02:49.640 --> 02:56.720
Yeah, later on, we got HP2, great, wonderful, HP2 has streaming in there, right, you can

02:56.720 --> 03:06.600
have multiple streams, and so then also came WebSockets on top of HP2, that was in 2018,

03:06.600 --> 03:14.040
and it gives you the ability to run many WebSockets connections over one HP2 connection,

03:14.040 --> 03:18.040
or many WebSockets, let's call them sessions.

03:18.040 --> 03:25.680
Later on, we got X4 lucky and got HP3, and that's the thing I'm very excited about, and

03:25.680 --> 03:31.400
folks also standardized WebSockets on top of HP3, now great, we get multiple streams,

03:31.400 --> 03:37.520
we get very mechanism against takeoff line blocking, wonderful, turns out no one really

03:37.520 --> 03:42.440
implemented, I'm not aware of any major deployment out there, nor am I aware of any browser

03:42.440 --> 03:48.080
engine implementing it, if you have plans around that, please reach out to me, I'm interested

03:48.080 --> 03:55.360
to chat about it, so yeah, we have two ways to run WebSockets on HP1, HP2, HP3, not really.

03:55.360 --> 04:00.760
Where are we in the internet stack when we're talking about WebSockets, all of you are

04:00.760 --> 04:06.760
currently familiar with IPv4, IPv6, then we have the two pillars on the left, both running

04:06.760 --> 04:13.480
on top of TCP, we have some kind of security layer, so TLS 1.3 preferably, and then we

04:13.480 --> 04:20.480
have HP1, HP2 running on top of that, that gives us HP semantics, so get post-put, and so on,

04:20.480 --> 04:25.480
and then with those HP semantics, we can then do the upgrade of going from a standard

04:25.480 --> 04:31.160
HTTP connection to a WebSockets stream, we can do that on HP1, HP2, as I said, there's

04:31.160 --> 04:36.200
the standard for HP3, but I'm not aware of any deployments out there, so not really

04:36.200 --> 04:38.440
usable there.

04:38.440 --> 04:45.840
So we are very much constrained to whatever TCP gives us, on higher level, we cannot get

04:45.840 --> 04:53.560
anything more than what our lower levels make available to us, and this is very much where

04:53.560 --> 04:58.600
a lot of downsides come from for WebSockets, and I want to walk through through the various

04:58.600 --> 05:03.160
downsides here, you already have one on the screen, and then later on, well, we are of course

05:03.160 --> 05:11.960
going to compare that to WebTransport, so first thing, very WebSockets specific, the WebSockets

05:11.960 --> 05:18.760
upgrade, you see this pattern a lot, when you look at various web implementations, usually

05:18.760 --> 05:25.800
you have a one-round-trip upgrade mechanism, so on the very left here you see the HP upgrade

05:25.800 --> 05:30.160
to WebSockets, the client is requesting it, the server says one-on-one switching protocol,

05:30.160 --> 05:36.280
all good, let's go, and then you have a bidirectional stream, but this unfortunately

05:36.280 --> 05:41.400
costs you a whole round trip, right, as in, let's say you have a 30 millisecond round trip

05:41.400 --> 05:46.200
time, then you're already paying for a round trip on TCP, you're already paying for a round

05:46.200 --> 05:51.240
trip on TLS 1.3, and now you're paying for another round trip just to get your WebSockets

05:51.240 --> 05:59.240
session going. There is the trick of doing this a little bit more optimistically, support differs

05:59.240 --> 06:05.480
across platforms, so what we could do is send the upgrade token, already optimistically send

06:05.480 --> 06:10.440
data on the WebSockets session, saying like, I'm sure the server will accept this, and then

06:10.440 --> 06:15.080
the server says one-on-one switching protocol is great, and then it's also sending responses to

06:15.080 --> 06:20.840
whatever you send earlier. So this saves you on a round trip, but you're having this optimistic

06:20.840 --> 06:29.160
pattern in there, if the server says, nope, not talking WebSockets to you, then in the HP2 case,

06:29.160 --> 06:35.160
the whole thing fails, you send data that was never useful, and in the HP1 case that is actually

06:35.160 --> 06:40.840
a potential security attack, where if you don't control what, if you have an entrusted

06:40.840 --> 06:46.760
client that can put anything into the optimistic data, the server after rejecting your initial

06:46.760 --> 06:52.280
upgrade request will then interpret the optimistic data, potentially it's an HTTP request,

06:52.280 --> 06:58.760
so your attacker could put anything in there and then take control in some way of the connection.

06:58.760 --> 07:05.880
So in the default case, as I said earlier, one RTT mostly, there is the optimization around

07:06.520 --> 07:15.640
doing this optimistically, but it's not implemented everywhere. From here, the major thing

07:16.520 --> 07:21.240
of WebSockets, and that's very much WebSockets suffering from what it is running on top of,

07:22.360 --> 07:29.480
is head of line blocking. For those not familiar with this, I will go a little bit into this.

07:29.880 --> 07:37.240
So imagine you have a B-directional communication substrate, whatever it is, it might be

07:37.240 --> 07:43.160
TCP connection, WebSockets, anything out there, and so it's a single larger stream where you put

07:43.160 --> 07:48.280
multiple streams inside, so you have one packet for stream 1, stream 2, stream as sorry,

07:48.280 --> 07:52.760
stream 1, and then later on stream 2, so stream 2 is behind all of this, and you're sending this

07:52.760 --> 07:57.560
over the wire, and it makes it to the receiver, but unfortunately the first one doesn't.

07:58.520 --> 08:04.760
So now stream 2 is independent of stream 1, as in the receiver could already consume stream 2,

08:04.760 --> 08:12.280
like the data in it, but given that TCP is always ordered, you cannot consume whatever is in stream 2.

08:13.080 --> 08:18.360
It's not available to you. So you will have a retransmit of this one packet on stream 1,

08:18.360 --> 08:27.240
and only then the receiver can then read all of the frames for stream 1, and then later on stream 2.

08:27.240 --> 08:31.800
So this is not ideal. In general, the idea of head of line blocking, you see this everywhere in the

08:31.800 --> 08:39.000
web is the idea that independent data is blocked because something at the head of the queue

08:39.000 --> 08:47.000
is not yet ready to be read. And we have this problem both on the session level in WebSockets,

08:47.000 --> 08:52.520
and on the TCP stream level, as in like if you have different kind of things that you send over

08:52.520 --> 08:57.240
the single WebSocker connection, the receiver can only read that in order. If you have

08:58.120 --> 09:02.600
independent things that you send on one TCP connection, the receiver can only read that in order.

09:02.600 --> 09:07.080
If the head is delayed, everything behind that is delayed. That's very much problematic.

09:10.840 --> 09:18.680
Next, given that we're running on TCP, as I said, WebSockets is using HB1, HB2, both running on

09:18.760 --> 09:26.280
to TCP, there is no such thing as unreliable delivery. TCP will always give you reliable delivery.

09:26.280 --> 09:32.440
Now don't get me wrong, that's a good idea. Don't implement your own transport protocol just

09:32.440 --> 09:38.040
to get this. But it is a problem in some cases where you want unreliable delivery. Say, for example,

09:38.040 --> 09:44.520
you have a life stream, let's say a packet is lost. Given that it's a life stream, you probably

09:44.520 --> 09:49.080
don't care whether that packet is retransmitted. Because the life stream is moving on, if that

09:49.080 --> 09:54.200
one packet is gone, you don't really care. You don't want that retransmitted. Because that retransmitted

09:54.200 --> 09:58.840
would take up bandwidth, you would throw it away anyways, that the receiver side. And it is

09:59.560 --> 10:03.000
competing with the other traffic that might be more important on that connection.

10:03.800 --> 10:11.240
So WebSockets, unfortunately, no unreliable delivery. Next one, connection migration. Here you see

10:11.800 --> 10:17.880
my big emoji game. Let's imagine you're in the house and you see the bus. You're on your

10:17.880 --> 10:24.680
phone, you are, again, say life streaming, something over your Wi-Fi. Now you run to the bus,

10:24.680 --> 10:32.120
and you exit the house, exit the reach of your Wi-Fi, and you're switching to your cellular,

10:32.120 --> 10:37.400
or your phone does that automatically. So you're switching networks. Now what's going to happen?

10:37.400 --> 10:42.120
Well, your source IP address is going to change. Your source IP address is going to change from your

10:43.320 --> 10:49.400
home source IP to your cellular source IP. You don't have your own that is knitted, but

10:49.400 --> 10:55.720
over all you can think that way. So what's the problem here for TCP? TCP always operates on the

10:55.720 --> 11:02.840
fortible. So on source IP, source port, source destination IP, destination port. If the source IP

11:02.840 --> 11:08.920
changes, your TCP connection breaks. Now there are tricks, very tricks, but those are not very,

11:08.920 --> 11:14.840
very widely deployed. So very much your TCP connection breaks. And that also means everything that

11:14.840 --> 11:21.080
you run on top of it also breaks. So for example, if you have a life stream running while you run

11:21.080 --> 11:28.120
to your bus, then that life stream is also running break. Not great. So on WebSockets, given that

11:28.120 --> 11:35.160
it's only running on TCP, we don't have connection migration. And then lastly, this is more

11:35.160 --> 11:40.760
informational here. Browse the support, as I mentioned, HB1, HB2. There are a lot of benefits

11:40.760 --> 11:47.000
of HB3 beyond what I just listed. And that's a bummer, WebSockets right now, not supported beyond that.

11:49.640 --> 11:54.120
That's enough about WebSockets. Now let's talk a little bit about WebSransport,

11:54.120 --> 12:02.920
as in the successor to WebSockets. WebSransport is very much a new API on the web. It's an

12:02.920 --> 12:09.880
ongoing effort, both at the ITF and the W3C being standardized there. I will have a slide to go more

12:09.880 --> 12:16.440
a little bit into detail on the standard's bodies. The focus is very much on HB3. And you can see

12:16.440 --> 12:20.840
later that all the properties that are listed are mostly solved actually at the lower level HB3,

12:20.840 --> 12:29.080
not so much by redesigning WebSockets to WebSransport. So focus is on HB3, but HB3 is not possible

12:29.080 --> 12:33.640
everywhere in the web. Nor is it deployed everywhere in the web, so there's also being developed

12:34.680 --> 12:45.800
fallback to HB2 in case HB3 is not available. In the major big step of WebSransport is

12:45.800 --> 12:54.920
very fine-grained flow control, per session, and per stream, which for example gives us independent

12:54.920 --> 13:02.200
reliable streams, so reliable delivery similar to TCP streams, but also unreliable delivery similar to

13:02.200 --> 13:07.960
UDP datagrams. And with these various mechanisms, we can entirely work around the problem of

13:07.960 --> 13:12.520
headline-bocking, the thing that I showed earlier was stream 1 and stream 2 were stream 2

13:12.520 --> 13:19.240
weights on anything in stream 1. So this is basically one of the big goals of WebSransport.

13:20.520 --> 13:27.080
Cool, let's walk into some use cases first and then into the lower levels. I'm just listing a

13:27.080 --> 13:35.320
couple of things here, those are not mine. For example, let's say you want to implement a cloud game,

13:36.040 --> 13:42.760
and you want the sending of the user input to be very reliable as in every click you do.

13:43.640 --> 13:48.600
Well, at the same time, you want to push video frames back from the server, and you don't really

13:48.600 --> 13:54.280
care about whether individual frames are lost, right? It's life after all, so if they're lost,

13:54.280 --> 13:58.520
you definitely don't want them to be retrospective, you want this to happen in an unreliable fashion.

13:59.240 --> 14:04.440
Other ideas, like life-streaming, very similar to that, imagine collaborative editing.

14:05.320 --> 14:10.120
You definitely don't want a change to be lost, right? As in you want that to be retransmitted,

14:10.120 --> 14:15.640
but a cursor update of your colleague, if it gets lost, you don't really need it. Retransmitted,

14:15.640 --> 14:21.160
the next cursor update will just update you. You have ideas of internal things where you have

14:21.160 --> 14:28.200
many streams of events that you want to consume, or you can imagine a financial ticker,

14:28.200 --> 14:34.920
where always the latest packet that they just update on the price matters, but if one later on gets

14:34.920 --> 14:41.320
dropped, you just wait for the next one. A lot of use cases, would you right now not perfect

14:41.320 --> 14:47.720
for a web socket and where web transfer very much targets to be the protocol in need?

14:47.720 --> 14:54.200
Where do we place web transport? This is exactly the same graphic as before, just the upper layer

14:54.200 --> 15:01.000
changed. We have IP at the bottom, then TCP, of course, in UDP. We have the three pillars,

15:01.000 --> 15:09.160
HB1, HB2, and HB3, and here on the top right, you see web transport, very much targeting HB3,

15:09.160 --> 15:15.400
so that's the main playground we're trying to be in. Then we have a fallback on web transport

15:15.400 --> 15:22.360
over HB2, and there are efforts to design web transport over HB1, even though that is very

15:22.360 --> 15:30.520
difficult, so I'm not sure how successful that's going to be. As I said, this is actually

15:30.520 --> 15:35.240
not a web transport talk, but actually I just want to talk a lot about my favorite protocol

15:35.240 --> 15:47.880
quick and HB3. Now we're getting to that part. This I want to focus now on the third pillar,

15:47.880 --> 15:53.320
so HB3 and quick, because a lot of those properties then bubble up into web transport and make

15:53.320 --> 16:03.640
web transport, so what is quick and HB3? The most notable thing is instead of HB1 and HB2 being

16:03.640 --> 16:10.360
based on TCP, we're now basing everything on top of UDP. So we don't have the reliable guarantees,

16:11.640 --> 16:17.080
and the various congestion controllers available that we would have on TCP, but hey,

16:17.080 --> 16:21.480
we can roll out on, and that is basically all idea. So quick is very much a journal for a

16:21.480 --> 16:28.440
best transport protocol, you can think of it as TCP2 with TLS tightly integrated. It is on top of UDP,

16:29.160 --> 16:35.080
it encrypts a lot of its metadata. So obviously we want to encrypt the actual user data,

16:35.080 --> 16:40.760
right, that we have been doing for a very long time, but now we also want to move that encryption

16:40.760 --> 16:47.640
down to the lower protocol layers to, for example, encrypt more of the handshake of quick.

16:48.360 --> 16:56.040
We'll go, I think, a little bit into connection establishment. Maybe quick connections can be

16:56.040 --> 17:02.520
established in one RTT. I mentioned earlier TCP costs an RTT then TLS also costs an RTT,

17:02.520 --> 17:09.400
so you always have two on HB1 and HB2. On the other hand, HB3 merges the transport handshake

17:09.400 --> 17:15.000
and the security handshake and thus you get that in one RTT. That is huge for the web, right?

17:15.000 --> 17:20.120
As in, let's say you have 30 milliseconds around trip time. Imagine you can optimize your page

17:20.200 --> 17:26.600
load by 30 milliseconds. That is very big. On consecutive connections, quick goes even further,

17:26.600 --> 17:32.200
because it integrates the transport handshake and the cryptographic handshake together, it can

17:32.200 --> 17:37.400
do various tricks where on consecutive connections we can reuse some of the cryptographic material

17:37.400 --> 17:42.040
from the previous connection and actually do the whole connection establishment in zero RTT.

17:42.040 --> 17:47.240
As in, we can send our get requests right away with zero latency for the setup.

17:47.640 --> 17:54.360
Given that we are on top of UDP, we can play around with reliability guarantees. As I said,

17:54.360 --> 18:01.400
TCP only gives us reliable delivery. UDP gives us unreliable delivery. Quick is our reliability

18:01.400 --> 18:05.560
layer if we want it. If we don't want it, we can actually send things unreliable.

18:07.720 --> 18:14.600
And with those new mechanisms, streams being independent and we have unreliable delivery,

18:14.600 --> 18:18.840
we can then work around the various problems around head-of-line blocking, both within

18:18.840 --> 18:22.520
for example web transport session, but also lower layer on the transport layer.

18:23.960 --> 18:29.000
I mentioned earlier, connection migration will go a little bit into that, and then all of this

18:29.000 --> 18:35.160
is a new shiny protocol. There's very much built to last well designed, and given that most of

18:35.160 --> 18:42.280
it is encrypted, boxes in the middle of the internet cannot mess as much with the quick protocol.

18:43.000 --> 18:48.920
Just an anecdote, after the quick handshake, all quick packets actually have only two bits

18:48.920 --> 18:55.240
that are encrypted. Everything else is encrypted in those packets. So any middle box would

18:55.240 --> 19:00.200
actually need the TLS key to mess with any of it, and thus hopefully middle box will not

19:00.200 --> 19:06.040
ossify the internet as much as today. It's currently like you can't roll out TCP2,

19:06.040 --> 19:10.600
because simply the middle box is still nowhere to this, and thus they're going to break.

19:12.760 --> 19:20.120
Okay, so I mentioned this earlier, the connection establishment, it's huge on HTTP3.

19:21.000 --> 19:28.600
Here you basically see that HTTP3 is twice as fast as HTTP2 in terms of setup time. Note these are

19:28.600 --> 19:34.280
observational data. As in maybe the whole internet, all the fast servers just use HTTP3,

19:34.280 --> 19:41.160
and all the slow servers just use HTTP2, maybe unlikely. I would bet that this has to do

19:41.160 --> 19:46.360
to the fact that we have one RTT connection establishment, and sometimes zero RTT connections

19:46.360 --> 19:52.040
establishment. In terms of adoption, and this is very much relevant for web transport, right?

19:52.040 --> 19:57.480
As I said, web transport focuses on HTTP3, so if HTTP3 is not available everywhere, that's a

19:57.480 --> 20:03.720
difficult story for web transport. HTTP3 adoption, we currently see around 20 to 30 percent,

20:03.720 --> 20:09.560
the file box traffic using HTTP3. There's great other players in the internet see way more,

20:09.640 --> 20:15.720
as in it is possible to run HTTP3 across the web. Some other players see up to 95 percent.

20:17.560 --> 20:23.800
We have various tricks, maybe some of you out of happy I go of HTTP3, which we will soon be

20:23.800 --> 20:31.480
lending in file box to actually increase that HTTP3 share. Okay, with that, we have the lower level,

20:31.480 --> 20:37.240
and we know what quick an HTTP3 is, what does that mean for web transport? Well, first off,

20:37.560 --> 20:43.320
the web transport upgrade. It can be done in zero RTT. As in, we can do that optimistic

20:43.320 --> 20:50.840
dense that we also had earlier with HTTP2 and web sockets. As in, I sent both the upgrade request

20:50.840 --> 20:57.640
and already sent data. But instead of single reliable byte stream, I can actually start multiple

20:57.640 --> 21:03.560
streams already, and I can, for example, send the data gram already. And then when the server responds

21:03.640 --> 21:07.400
with a 200, they can already react to all of the stuff I already sent.

21:10.040 --> 21:15.160
In terms of head of line blocking, given that we're running on top of UDP instead of TCP,

21:15.160 --> 21:20.280
we don't have one single reliable byte stream as in things in the back, get delayed by the things

21:20.280 --> 21:28.680
in the front. Instead, the stack can reach UDP data grams one after the next and then propagate them up.

21:28.680 --> 21:34.360
So, for example, in the stream 1 stream 2 use case, if stream 1 gets delayed, that doesn't matter

21:34.360 --> 21:40.280
for stream 2. Stream 2 data can already be bubbled up. As in in your web transport session,

21:40.280 --> 21:45.800
if your stream 1 has a packet loss, your stream 2 doesn't need to be delayed due to this.

21:47.720 --> 21:52.680
So, we get the head of line blocking. We get unreliable delivery. Previously, we were running on TCP.

21:52.680 --> 21:58.120
There is no unreliability on TCP. Now, we're running on quick, which has UDP and does unreliable

21:58.120 --> 22:02.520
data grams actually as a feature building to quick, and we can leverage that on the higher level

22:02.520 --> 22:07.720
in web transport where we can say, hey, this piece of data, I'll send it to the server. If it doesn't

22:07.720 --> 22:13.000
make it there, please don't retransmit it. I just needed a time if it doesn't make it retransmission

22:13.000 --> 22:20.440
is useless. We have things like connection migration. Again, here, me running to the bus,

22:21.480 --> 22:27.320
quick will notice that the connection is migrating from one path over to another,

22:27.400 --> 22:32.920
and thus has a past challenge to validate that the new path is valid and will then switch over.

22:32.920 --> 22:40.920
It is not dependent on the source IP staying static. And lastly, browser support, as I said,

22:41.560 --> 22:46.360
it's very much the focus on HTTP3 and there is upcoming HTTP support as well.

22:48.280 --> 22:53.880
Support across browsers. You've already seen similar slides a lot today in this room.

22:54.760 --> 23:01.960
We do have a web transport support on Chrome Edge 5X Opera. Safari, you still see here in red.

23:02.760 --> 23:07.480
They I believe have like a developer flag, which you can enable and then use web transport

23:07.480 --> 23:13.720
in Safari as well. And I heard it is shipping soon as in basic web transport support in Safari,

23:13.720 --> 23:16.040
which is very exciting because then we have it in all of these.

23:16.040 --> 23:26.600
Status at the standard bodies at the W3C, it is going to wider review for candidate

23:27.480 --> 23:33.720
recommendation soon. So that's a very good step. So most more of the APIs are being standardized.

23:33.720 --> 23:39.320
And then at the ITF, we're currently on HTTP3 to separate drafts, actually for the two versions,

23:39.320 --> 23:44.680
on draft number 14 and the other one draft number 13. I'm not so much involved with the W3C.

23:45.480 --> 23:51.000
I am involved in the ITF and I don't see major changes, but yeah, you never know before the RC is published.

23:52.520 --> 23:55.560
In terms of users, yeah, adoption is low. That's the big problem.

23:57.320 --> 24:02.200
There, I'm not aware of any major deployments today using web transport.

24:03.080 --> 24:08.200
Though there is a larger working group at the ITF trying to pull more and more of media streaming

24:08.200 --> 24:13.320
and the like over two to web transport. So in case you're interested in that,

24:13.320 --> 24:19.000
definitely follow the media of a quick working group. You can take it and try it out.

24:19.000 --> 24:23.320
There are various test websites. I uploaded these slides so you can just click the link there.

24:24.200 --> 24:29.240
One test website, I linked here. If you want to play around this with this yourself,

24:30.040 --> 24:35.080
I really like the web transport goal implementation that's very helpful. And then on the browser side,

24:35.080 --> 24:39.880
is it easy as opening a web transport connection, waiting it for it to be ready. And then,

24:39.880 --> 24:44.280
hey, you can send unreliable datagrams in the browser. Isn't that always what you wanted?

24:46.840 --> 24:53.800
Note, the API changed slightly on the draft side. This is still what all major browser's implement.

24:53.800 --> 24:57.800
So if you want to get going, that's the one. If you want to follow the latest spec,

24:57.800 --> 25:03.160
which we will update in the browser soon, then this changed slightly, but not too much.

25:04.600 --> 25:08.680
That's it for my end. If you have questions, I think we have a couple more minutes.

25:09.480 --> 25:15.480
One question. I will be outside after this talk. So if you want to talk to me, just find me there.

25:16.280 --> 25:21.560
Help us build all of this, right? It's not us alone in building and healthy internet as all of us.

25:22.600 --> 25:27.320
Yeah, and if you want to reach out to me, this may email address. And I do have stickers of my most favorite

25:27.320 --> 25:31.960
protocol, called Quick. So if you want some of those, yeah, find me somewhere.

25:32.600 --> 25:34.600
Cool. Thank you.

25:38.680 --> 25:41.240
You