Re: Multipath QUIC prototypes

Behcet Sarikaya <> Mon, 13 September 2021 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F18623A0977 for <>; Mon, 13 Sep 2021 09:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d6ZhvFPxWLwO for <>; Mon, 13 Sep 2021 09:37:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DD793A096C for <>; Mon, 13 Sep 2021 09:37:47 -0700 (PDT)
Received: by with SMTP id v10so21742907ybq.7 for <>; Mon, 13 Sep 2021 09:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=1X0us0BjfSwqxCWs0DPEEqdC3ZZC53uRrCVA6/+G0Zw=; b=hTsVvxr99GDsN+2iCrX2mpsSOiHeCqRJIrnBKx8jx5Vb1KPNMGgmcJu6dOZ/ISuwzG Gm+VaHAvPYBHvUX0WFq8sWpjsu/kwXBqAuSuUQYIE8LzNqSWyk8VCuJ1o5ez8w28vLVi B6cKPKyiCAkmH4R7MBE72zGMvMKWMijvpzJT+65bedDCMJaRlZybnw3WgGo9jx1eh7af 2ZkR7LUnAiFROCkfvBV6qflFPe7WMfE0LS/RUv/D2CO0/9HQfAmASeve1Yr1301w18Jz 0YjhriMR2JPP+esZDGPXORVCi81qFjnHbSumEZ4UXMl+h3OOMzH8ymYlBdoUsEj/873Q U4CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=1X0us0BjfSwqxCWs0DPEEqdC3ZZC53uRrCVA6/+G0Zw=; b=A1XBDPWyc4E+RdvhblKqY8SySMRbO1O/AjBXa0vzugACj23Pa0tsuII7xMfAnbMyab yuekCaAM3qDeC5QpOHu5DnGfoAB1zlKjpv1TgXPvfo60xMOmz41rjHFfraQzw5bbXBSt KgofNd2tWobIcD6W38v0SYhCHXm5xPJGR1riekfmCqNP080T8DqUDVKd9bXpg4fM3+Ca 8sJMWn4OZoQXkoT09+6OM9225po9aJJkGWx9fhf1MfVw1zgBfYTjxgjxgeXXcJAOS7lo z/ccfOCoCYjSa6bfHL2kPYzII8w6Fdrml3G8BqpZ7lL0CdsZ2QOSRJZIx8dRoUNve1kG uVIg==
X-Gm-Message-State: AOAM530W3XctYQn5L6zu9QuC09JJUu8cAuasoaRE+0M4RDA3awm6zRnx bouCqa5PnOVoHgeIvNxV/FgKIX5HFssTDKX2UHY=
X-Google-Smtp-Source: ABdhPJy8P+Tp5zAquKL6eRvqkwyogNKl38oMrmodH4MY0iMopEuqNuzxMcFcjLq3ZHgoUO2UBIXeFKr1elWYy6Aj8tw=
X-Received: by 2002:a05:6902:603:: with SMTP id d3mr17560257ybt.28.1631551065394; Mon, 13 Sep 2021 09:37:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Behcet Sarikaya <>
Date: Mon, 13 Sep 2021 11:37:34 -0500
Message-ID: <>
Subject: Re: Multipath QUIC prototypes
To: Phillip Hallam-Baker <>
Cc: Michael Eriksson <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000af92b505cbe315fe"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Sep 2021 16:37:52 -0000

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


On Fri, Sep 10, 2021 at 11:18 AM Phillip Hallam-Baker <>

> 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=
>> 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