Re: Multipath QUIC prototypes

[Behcet Sarikaya <[e-mail]>]

Good luck Philip.
Maybe you like to reinvent the wheel?

Behcet

On Fri, Sep 10, 2021 at 11:18 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> I am doing non-QUIC experiments in the same space.
>
> The biggest and most important innovation in QUIC is that it eliminates
> the dependency of transport area innovation on kernel updates. So it is far
> from clear that QUIC is going to be THE replacement for TCP, it may just be
> A replacement.
>
> The other reason for my approach is that right now there is really little
> to be gained for my project from layering over QUIC since I would have to
> implement an already large spec myself. Publication of the QUIC RFCs is not
> the same as consensus on the feature sets/APIs exposed by popular libraries
> either.
>
> And then there is my plan to encrypt every single bit of the UDP payloads
> and to provide native onion routing support.
>
> So I am very interested in this work and will be following but I am taking
> a different path for now and it might well turn out to be the case that
> there is room for a transport optimized for the needs of Web browsing and a
> separate transport optimized for the needs of Web Services.
>
>
>
> On Thu, Sep 9, 2021 at 2:59 AM Michael Eriksson <michael.eriksson=
> [e-mail]> wrote:
>
>> Hi,
>>
>> At Ericsson Research we are doing some prototyping of multipath QUIC (of
>> the fully parallel kind). So far, we have very rudimentary support in our
>> prototype but are about to take the next step.
>>
>> Our initial implementation uses a single packet number space, which
>> turned out to be a pretty clean addition to the path migration mechanism.
>> Some care has to be taken with the ACK handling on both sides, but so far
>> it has been straightforward. The key is that the sender has to keep track
>> of over which path each packet was sent, but that is trivial to do. Some
>> smartness with the ACK ranges is also needed, but you already need to prune
>> them for the single path case.
>>
>>
>> This is what I think I know about existing "active" multipath
>> implementations, please correct me if I'm wrong:
>>
>> - picoquiq has experimental but undocumented support (open source)
>>
>> - Alibaba are running A/B tests with real users and have published a
>> paper about it. The implementation is planned to be open sourced (this
>> seems to be delayed).
>>
>> - Quentin De Coninck et al at UCLovain have a prototype and paper on
>> multiflow QUIC, using unidirectional "uniflows" (open source)
>>
>>
>> Are there any other existing or planned multipath prototype activities in
>> the QUIC community? I would be particularly interested in:
>>
>> - Open source implementations (preferably in Rust :-))
>>
>> - Public servers for interop testing
>>
>> - Designs with a single packet number space and the experiences
>> collected. Separate number spaces, as in draft-liu-multipath-quic, will of
>> course work; however, it would be interesting to also understand the
>> cleaner single PN space alternative.
>>
>>
>> Best regards,
>> Michael Eriksson
>>
>