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.
We pass all the packets to quick, and to the quick stack, we use the rest implementation.
There is also entirely in Rust, and Quinn will just ignore all the packets that don't have the grease bit on.
But this is not ideal. The other thing that's not ideal is we hide multiple paths inside a single socket.
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.
We have one or more direct paths, usually you get both IPv4 and IPv6 direct paths these days or very often anyways.
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.
And there are three drafts essentially, ITF drafts that exist, that we would like to adopt more, and we are actively working towards that.
So the first one, under this discovery, this is done, this is like the very basic.
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.
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.
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.
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.
Basically, we get isn't encrypted, we also get reliable delivery because quick will retry the packets until it is acknowledged.
And this is actually fairly simple draft, it's written by Martin Seymour.
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.
It works by having a transport parameter, so a quick transport parameter is negotiated, then you notice.
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,
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.
So it's kind of event based, which makes it a bit nicer as well. This already exists.
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.
The next thing is like, you need to actually do the whole bunching.
This is a bunch more complicated. This is also written draft initially written by Martin Seymour.
This one is not, I'm not aware of anyone who's implemented this way yet.
We also haven't quite started that, we do in the next bit first.
There are two variations here, there's a quick multipass, which I'll get to in a second.
And that's essentially the version that we care about most.
But the idea here is essentially that, as you do address discovery already, you get to know the addresses that you have.
And then the server start sending, it's known addresses, it's known public addresses or any addresses that it knows to the client.
And the client will then combine those with its own, and then initiate whole bunching.
Wanting to notice that when I talk about server client here, that's strictly in the notion of quick rules.
So for us, everything is just a pair, it's just a note.
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.
The side that receives the first packet is accepting, and that's the server roll for quick.
So otherwise, that's only the reason you's client and server here.
A whole bunching, then itself, is kind of built on top of pathification that already exists in the quick specification.
The pathification already exists because some connection migration already exists in quick.
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.
And this is, when that happens, the server has to validate the path.
Has to validate that this is not someone just spoofing something and pretending the client has moved.
And for that, there is this part challenge, but response mechanism.
And that can essentially be used to hope and just well.
So the changes that changes that this makes is, it allows both sides to start doing this.
And when you initiate a whole bunching, you basically start both sides starting sending part challenge to the others.
That hopefully punches holes through the, any firewalls in between.
And eventually, they will start going through because they are trying to reach each other.
And then you have, and then the quick stack basically can detect that this is a, the path is established.
And then it can start using a second path.
The second path, sort of, is sort of a multi path comes in.
Multi path is a, is a fairly much, much more used draft, I guess.
There are several implementations of this already.
And we are currently in, in the process of implementing this in, in Quinn as well.
Multi path is essentially this, this idea of like you can have several IP paths between, between different, between the same endpoints.
I've already mentioned that you often have this in IPv4 IPv6 is, is, is a common common layer ready to paths.
In our case, we also have the relay server.
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.
And right now, we don't have this. So right now, when, when we do this inside outside of, well, decides kind of quick.
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.
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.
So that's the reason why we have very much interested in in the multi path, uh, specifications as well.
Multi path has this notion of path references, this again, to, to frame types.
And path available path path backup, we're almost done by.
Um, and so so for us, the basic idea is that our, our relay, really, connection would have a path backup.
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.
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.
So for example, if you have two IP paths that work, you, you may even send to both at the same time.
And you, you're, you're increasing bandwidth. Having said that, that is all somewhat experimental.
Not, um, yeah, the, uh, how to exactly do this path scheduling is, is, is not fully worked out yet.
And it's, in the, in the spec, it's kind of left open, uh, for further work or implementations really.
Um, all of this is not, uh, would, would not be possible without other people already having, having a lot of thinking about this.
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.
Uh, I mentioned Pico Quick. It can already do others discovery.
Um, together with us, uh, Martin Zayman has, um, he's, uh, go a quick library maintainer, I think.
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.
But, uh, yeah, it's, it's very good to have other people that are interested in this and try and figure it out.
Um, yeah, thank you. That was all, I had.
Thank you for your talk. Um, regarding the, uh, quick address detection, uh, how do you handle, uh, address important, uh, nothing, uh, translations.
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.
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.
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?
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.
Yeah.