Good luck Philip. Maybe you like to reinvent the wheel? Behcet
On Fri, Sep 10, 2021 at 11:18 AM Phillip Hallam-Baker <[email protected]> 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= > [email protected]> 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 >> >
