Add multipath

[flub]

No description provided.

[MikeRomaniuk]

Hi there!
Can you please say how much of the work is done already (just a ballpark figure will be enough)?
I would like to use quinn and the multipath feature feature is very important to me.
If this would be possible (I would need to ask the stakeholders) I may contribute to the development of the feature.

[flub]

@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.

[flub]

@MikeRomaniuk Can I inquire as to what your usecase is?

[MikeRomaniuk]

@flub, thanks for answering.
Sorry for the long time without an answer.
Unfortunately, I can't answer for the use case.
I would like to join you. I think I may answer whether I could help you in a few days or so.

[flub]

@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.

[MikeRomaniuk]

@flub, I might have understood your speech in the video wrong, so feel free to correct me.
You want to implement multipath, so after a NAT traversal, you could be able to connect a second direct path to get around any firewalls. After the connection, the first path will serve as a backing and/or will be used to increase bandwidth.
Did I get this right?

[flub]

@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.

[MikeRomaniuk]

@flub, thanks for clarification.
For the project I am about to start, the main goal of using multipath extension for QUIC is to maximise bandwith.
Right now I am considering tquic and your fork of quinn. I am researching the state of the available crates.
I am curious, when do you think, you will proceed to this stage?

[flub]

@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 AsyncUdpSocket and control over the TLS stack. Performance is also something we care about of course, and I'm fairly sure Quinn can also be improved this regard so more people who are interested in that can't do any harm.

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.

[MikeRomaniuk]

@flub I am very grateful for your explanations.
My goal here is to find out with which approach should I stick with.
Right now, I have 2 options:

• Implement async bindings for tquic (it doesn't have them)
• Help you implement multipath extension

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.

[shirok1]

@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 tquic crate interface is quite challenging to work with, though its scheduler does have a more modular "pluginized" structure.

You might be interested in @qdeconinck's fork of quiche at https://github.com/qdeconinck/quiche/tree/multipath-ietf-121. While it still lacks async support, the fork (of this branch and upstream) was created in October 2024, so it's fairly recent. There's likely potential to merge async support through some careful rebasing work.

I'm curious about which direction you're planning to take! Would love to collaborate on this problem if you're interested.

[MikeRomaniuk]

@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.