WEBVTT 00:00.000 --> 00:18.000 And we can distinguish the packets that are not quick, and we can handle those ourselves, so we can do stun, we can do coordinate whole bunching. 00:18.000 --> 00:26.000 We pass all the packets to quick, and to the quick stack, we use the rest implementation. 00:26.000 --> 00:34.000 There is also entirely in Rust, and Quinn will just ignore all the packets that don't have the grease bit on. 00:34.000 --> 00:41.000 But this is not ideal. The other thing that's not ideal is we hide multiple paths inside a single socket. 00:41.000 --> 00:51.000 So the quick stack things we just have a single socket, but in reality we are doing like whole bunching underneath, and we haven't path and network path by the real server. 00:51.000 --> 01:01.000 We have one or more direct paths, usually you get both IPv4 and IPv6 direct paths these days or very often anyways. 01:01.000 --> 01:09.000 So that's sort of the downsides, so that's why we are moving towards embedding all this whole bunching logic deeper into the quick stack. 01:09.000 --> 01:23.000 And there are three drafts essentially, ITF drafts that exist, that we would like to adopt more, and we are actively working towards that. 01:23.000 --> 01:29.000 So the first one, under this discovery, this is done, this is like the very basic. 01:29.000 --> 01:43.000 This is essentially the architecture that you always have, or it's very typical, and initially you start with a connection that goes through the release of it to be able to reach each other. 01:43.000 --> 01:57.000 But you want to establish the connection that goes more direct to know that, to do that, you need to know the public addresses that is on the other side of the firewall. 01:57.000 --> 02:07.000 So it's done, it's very, very simple protocol, it's like request apply based, and it is not encrypted, it is very easy to filter, it is very easy to do. 02:07.000 --> 02:17.000 You also have to think of it. So that's sort of the downsides, so the main benefit or the benefits we expect from, from doing this inside the quick stack. 02:17.000 --> 02:25.000 Basically, we get isn't encrypted, we also get reliable delivery because quick will retry the packets until it is acknowledged. 02:25.000 --> 02:31.000 And this is actually fairly simple draft, it's written by Martin Seymour. 02:31.000 --> 02:41.000 And this is already implemented, I think this will probably deploy by default in the release that we're supposed to do tomorrow, if I'm right. 02:41.000 --> 02:49.000 It works by having a transport parameter, so a quick transport parameter is negotiated, then you notice. 02:49.000 --> 03:01.000 And then every time the major difference with stone is that it's event based, so every time the server just sees a new IP address that you are sending from, because maybe you're migrated from Wi-Fi to mobile or something or whatever, 03:01.000 --> 03:09.000 it will send, it will just send a new frame, a new quick frame, that tells you what's the new address that it sees. 03:09.000 --> 03:14.000 So it's kind of event based, which makes it a bit nicer as well. This already exists. 03:14.000 --> 03:26.000 We also, this also has been implemented in PicoQuick already, and we are interoperable with PicoQuick in this, this all works, that's pretty cool. 03:26.000 --> 03:31.000 The next thing is like, you need to actually do the whole bunching. 03:31.000 --> 03:40.000 This is a bunch more complicated. This is also written draft initially written by Martin Seymour. 03:40.000 --> 03:47.000 This one is not, I'm not aware of anyone who's implemented this way yet. 03:47.000 --> 03:53.000 We also haven't quite started that, we do in the next bit first. 03:54.000 --> 03:59.000 There are two variations here, there's a quick multipass, which I'll get to in a second. 03:59.000 --> 04:05.000 And that's essentially the version that we care about most. 04:05.000 --> 04:14.000 But the idea here is essentially that, as you do address discovery already, you get to know the addresses that you have. 04:14.000 --> 04:24.000 And then the server start sending, it's known addresses, it's known public addresses or any addresses that it knows to the client. 04:24.000 --> 04:29.000 And the client will then combine those with its own, and then initiate whole bunching. 04:29.000 --> 04:36.000 Wanting to notice that when I talk about server client here, that's strictly in the notion of quick rules. 04:36.000 --> 04:39.000 So for us, everything is just a pair, it's just a note. 04:39.000 --> 04:49.000 But for quick, like when you, whoever sends the first, the very first packet in the connection to the other side is the client that's connecting side. 04:49.000 --> 04:54.000 The side that receives the first packet is accepting, and that's the server roll for quick. 04:54.000 --> 04:59.000 So otherwise, that's only the reason you's client and server here. 04:59.000 --> 05:06.000 A whole bunching, then itself, is kind of built on top of pathification that already exists in the quick specification. 05:06.000 --> 05:12.000 The pathification already exists because some connection migration already exists in quick. 05:12.000 --> 05:24.000 You can move from, like, your client, the client can already move from that work, because there is not rebinding, because there is moving from mobile to Wi-Fi or something like that. 05:24.000 --> 05:28.000 And this is, when that happens, the server has to validate the path. 05:28.000 --> 05:33.000 Has to validate that this is not someone just spoofing something and pretending the client has moved. 05:33.000 --> 05:37.000 And for that, there is this part challenge, but response mechanism. 05:37.000 --> 05:41.000 And that can essentially be used to hope and just well. 05:41.000 --> 05:47.000 So the changes that changes that this makes is, it allows both sides to start doing this. 05:48.000 --> 05:55.000 And when you initiate a whole bunching, you basically start both sides starting sending part challenge to the others. 05:55.000 --> 06:00.000 That hopefully punches holes through the, any firewalls in between. 06:00.000 --> 06:06.000 And eventually, they will start going through because they are trying to reach each other. 06:06.000 --> 06:14.000 And then you have, and then the quick stack basically can detect that this is a, the path is established. 06:14.000 --> 06:16.000 And then it can start using a second path. 06:16.000 --> 06:23.000 The second path, sort of, is sort of a multi path comes in. 06:23.000 --> 06:30.000 Multi path is a, is a fairly much, much more used draft, I guess. 06:30.000 --> 06:33.000 There are several implementations of this already. 06:33.000 --> 06:40.000 And we are currently in, in the process of implementing this in, in Quinn as well. 06:41.000 --> 06:49.000 Multi path is essentially this, this idea of like you can have several IP paths between, between different, between the same endpoints. 06:49.000 --> 06:58.000 I've already mentioned that you often have this in IPv4 IPv6 is, is, is a common common layer ready to paths. 06:58.000 --> 07:04.000 In our case, we also have the relay server. 07:04.000 --> 07:13.000 The nice benefit of this is that we get each path in, in, in multi path has its own congestion controller, it's own into you discovery and all that. 07:13.000 --> 07:21.000 And right now, we don't have this. So right now, when, when we do this inside outside of, well, decides kind of quick. 07:21.000 --> 07:31.000 We, we have to tell quick like, oh, we changed the path and the need you underneath you, just kind of reset these all back to initial values and start like figuring them out again. 07:31.000 --> 07:42.000 So I, um, a lot of packets will get lost when, when you switch paths and having being able to maintain several paths is, is really, would be really been beneficial. 07:42.000 --> 07:49.000 So that's the reason why we have very much interested in in the multi path, uh, specifications as well. 07:49.000 --> 07:56.000 Multi path has this notion of path references, this again, to, to frame types. 07:56.000 --> 08:00.000 And path available path path backup, we're almost done by. 08:00.000 --> 08:11.000 Um, and so so for us, the basic idea is that our, our relay, really, connection would have a path backup. 08:11.000 --> 08:18.000 Uh, you're always allowed to send on it. And then when you have any direct connections, you can, you can have a path available. 08:18.000 --> 08:29.000 This will also, uh, enable us to, like, once, once this is all working, multi path also has a notion of like, you don't necessarily have to send to just one path. 08:29.000 --> 08:36.000 So for example, if you have two IP paths that work, you, you may even send to both at the same time. 08:36.000 --> 08:42.000 And you, you're, you're increasing bandwidth. Having said that, that is all somewhat experimental. 08:42.000 --> 08:50.000 Not, um, yeah, the, uh, how to exactly do this path scheduling is, is, is not fully worked out yet. 08:50.000 --> 08:58.000 And it's, in the, in the spec, it's kind of left open, uh, for further work or implementations really. 08:58.000 --> 09:07.000 Um, all of this is not, uh, would, would not be possible without other people already having, having a lot of thinking about this. 09:07.000 --> 09:15.000 Um, both Christian, how to, my, I'm Martin Zayman. Basically, have, have been working, have been thinking about this and I'm working on this already. 09:15.000 --> 09:19.000 Uh, I mentioned Pico Quick. It can already do others discovery. 09:19.000 --> 09:27.000 Um, together with us, uh, Martin Zayman has, um, he's, uh, go a quick library maintainer, I think. 09:27.000 --> 09:39.000 And he, he, initially wrote those drafts, um, they're not implemented and, and I don't think there are current plans, uh, in, in the go library. 09:39.000 --> 09:47.000 But, uh, yeah, it's, it's very good to have other people that are interested in this and try and figure it out. 09:47.000 --> 09:51.000 Um, yeah, thank you. That was all, I had. 09:51.000 --> 10:11.000 Thank you for your talk. Um, regarding the, uh, quick address detection, uh, how do you handle, uh, address important, uh, nothing, uh, translations. 10:11.000 --> 10:21.000 Your, your, your port is dynamically, uh, changed. And if you go to the relay, it will be different changed. And if you go to, uh, your peer, how do you handle that, that, nothing. 10:21.000 --> 10:30.000 Uh, so this is kind of, uh, whole punching, uh, implementation. So there's depends on the, on the firewall, on, on the, not implementation. 10:30.000 --> 10:42.000 Um, many, many do not change it. Um, but also, when you, um, this is, this is a, this is a problem for, uh, this is a problem, because you do the others discovery, right? 10:42.000 --> 10:54.000 You, you, you, you, you, you, you, you find out what IP ports combination you have. Um, and if I ask in the relay server, and then you hope that the peer will actually be able to reach you on the same one. 10:54.000 --> 10:56.000 Yeah.