Add multipath #28
Add multipath #28
Conversation
divagant-martian
force-pushed
the
multipath-quinn-0.11.x
branch
from
6f37612 to
f5485c2
Compare
divagant-martian
force-pushed
the
multipath-quinn-0.11.x
branch
from
6fa6b81 to
f3f1a44
Compare
|
Hi there! |
|
@MikeRomaniuk This is still very early right now, maybe like the first 5% if that. We are still in the process of restructuring things for the basic building blocks for multipath to be there. If you want to help you can take a look at the code so far, but it is currently still rather difficult to point at anything. It will probably be easier to jump in once we have the most basic 2-path connection working. But if you're keen to really help, right now it is mostly a case of trying to understand what would be a useful next step based on the specs and code. And then try and implement some of it. With just two of us this seems to move us forwards so far. |
|
@MikeRomaniuk Can I inquire as to what your usecase is? |
|
@flub, thanks for answering. |
|
@MikeRomaniuk The usecase does kind of matter, because we have a very specific usecase in mind (documented in my fosdem talk, though the recording is terrible - i should re-record that sometime). We want to do the absolute minimum we can do for our usecase, and this keeps the number of public APIs that will be needed small as well. The multipath spec does give you enough to make a largely interoperable protocol, but also still leaves a lot of things as essentially further research topics. The largest one is probably packet scheduling, also things like how to interoperate with the ack-frequency spec and probably a bunch more that escape me right now. So what you want to get out of this does matter in that regard. |
|
@flub, I might have understood your speech in the video wrong, so feel free to correct me. |
|
@MikeRomaniuk Yes, more or less. Our "typical" case is to establish the connection via a relayed path, we'll use an IPv6 private address space IP to identify paths via the relay and handle that in our impl of Quinn's AsyncUdpSockt trait. This path will be set as PATH_BACKUP. Then combine draft-seeman-quic-nat-traversal with multipath to open another path using real IP addresses and mark that path as PATH_AVAIALBE. This will give us very simple packet scheduling semantics, I think the multipath part of this it's about the simplest version of multipath you can build. Once we have this working stable and reliable we will probably start looking at more advanced packet scheduling, there are a lot of possible things, as you say maximise bandwith by using multiple paths, or interactions with lost packets etc. But that is much further down the line for us, we really want to have the simplest multipath first. |
|
@flub, thanks for clarification. |
|
@MikeRomaniuk We would like to get to a stage where we can schedule packets on multiple paths at the same time to increase bandwidth. But as I explained for us that's not a high priority and not yet on our roadmap. But that doesn't mean we wouldn't love it if someone else figured out what good behaviour and a nice API is there. So we'd totally accept contributions. (Though at this stage packet scheduling is still some way away.) I'm not sure what your goal is here, because tquic already has multipath and claims to care about performance (I have never tried it). Quinn is not the highest performant QUIC stack around so might be worth to benchmark even just single-path connections to see if they meet your goals. We also had other considerations like being able to use the Lastly I'd like to repeat what this repo says in the readme: we intent to upstream anything that's not a gross hack and would discourage anyone from depending on us directly because we may make changes not very nice to users. Just be aware of that. |
|
@flub I am very grateful for your explanations.
Honestly, I would rather use quinn over tquic, since it is widely used in the community and I believe will be a better choice in the longrun. I will need to talk to the team to take into account their opinion and I will let you if we would decide to proceed our way with you. |
|
@MikeRomaniuk Hello, I'm also working on an MPQUIC-based project (specifically for my bachelor's final year project), focusing on developing custom MPQUIC schedulers. I've found that the event-based You might be interested in @qdeconinck's fork of I'm curious about which direction you're planning to take! Would love to collaborate on this problem if you're interested. |
|
@shirok1 thanks for the recommendation! I am very glad that you are interested in QUIC and the problem I am about to tackle. However, I cannot invite you to participate, since this is not my personal project. |
Did you progress on your evaluation? Would be good to know either way what the outcome is. |
|
Hi @flub! |
@MikeRomaniuk No worries, all the best! |
This commit uses an allow directive to suppress the following error:
```
warning: the `Err`-variant returned from this function is very large
--> quinn-proto/src/endpoint.rs:525:10
|
525 | ) -> Result<(ConnectionHandle, Connection), AcceptError> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `Err`-variant is at least 136 bytes
|
= help: try reducing the size of `endpoint::AcceptError`, for example by boxing large elements or replacing it with `Box<endpoint::AcceptError>`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#result_large_err
= note: `#[warn(clippy::result_large_err)]` on by default
```
Because AcceptError and all of its descendants fields are public,
excepting a descendant that contains a usize, it is impossible to reduce
the byte size of AcceptError without semver breakage.
Clippy is warning that the size of RetryError (both proto and quinn's versions) are excessively large for a Result Err variant. This function fixes these warnings by boxing the contents of both.
* make transport config and transport parameters uniform * remove comment from docs * keep track of the local and remote max path ids * add constant * clippy fixes
Green CI again on stable
…h-quinn-0.11.x # Conflicts: # quinn-proto/src/connection/mod.rs # quinn-proto/src/connection/spaces.rs
…h-quinn-0.11.x-b2b930a-merges
…h-quinn-0.11.x-b2b930a-merges # Conflicts: # .github/workflows/rust.yml # quinn-proto/src/connection/spaces.rs
…h-quinn-0.11.x-b2b930a-merges
…h-quinn-0.11.x-b2b930a-merges
…h-quinn-0.11.x-b2b930a-merges # Conflicts: # quinn-proto/src/connection/mod.rs # quinn-proto/src/connection/paths.rs
…h-quinn-0.11.x-b2b930a-merges # Conflicts: # quinn-proto/src/connection/mod.rs
…h-quinn-0.11.x-b2b930a-merges
…h-quinn-0.11.x-b2b930a-merges # Conflicts: # .github/workflows/book.yml # .github/workflows/rust.yml
…h-quinn-0.11.x-b2b930a-merges
…h-quinn-0.11.x-b2b930a-merges
…pSocket` in connections
…recv` take `&mut self`
This reverts commit 44a3dc6.
This also includes removing async-std support. These are commits on top of which Phillip's ones are made
* Add OpenPath::path_id and some docs * Try and word this a little better
The previous logic does not work: the client has the path validated immediately, even before any packet is sent. Now we need to have received an authenticated handshake packet before we stop allowing migration. This exposes us to a little more off-path attacking, but in terms of processing all the earlier packets: only the correct server can generate an authenticated handshake packet IIUC.
* Fix WeakConnection::upgrade It created a ConnectionRef that did not increment the manually-tracked reference count inside the Arc<ConnectionInner>. This triggered the ConnectionRef's Drop impl to actually drop the connection. This works around this by using the fact that the ConnectionRef's Clone impl does know how to manipulate the reference count in a way that works together with the ConnectionRef's Drop. I think this is preferred over manipulating the ref_count directly in the WeakConnectionHandle since that code is closer by. * Nicer implementation
This in the same style as the other frames are logged. It's very confusing to not have a trace log of this.
No description provided.