Re: Multipath QUIC prototypes

Christian Huitema <> Thu, 09 September 2021 12:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25CA83A0A03 for <>; Thu, 9 Sep 2021 05:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3OCwzW3zh_f8 for <>; Thu, 9 Sep 2021 05:46:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83FC73A09FE for <>; Thu, 9 Sep 2021 05:46:47 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1mOJRx-0007mn-RE for; Thu, 09 Sep 2021 14:46:46 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4H4zKD32ZlzLvw for <>; Thu, 9 Sep 2021 05:46:40 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1mOJRw-0005YG-8H for; Thu, 09 Sep 2021 05:46:40 -0700
Received: (qmail 25341 invoked from network); 9 Sep 2021 12:46:39 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 9 Sep 2021 12:46:39 -0000
To: Michael Eriksson <>, "" <>
References: <>
From: Christian Huitema <>
Subject: Re: Multipath QUIC prototypes
Message-ID: <>
Date: Thu, 09 Sep 2021 05:46:39 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------2C75626B3A1D5DBDEEB8F7F2"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCKYs Qqr2S84FWn0PiOiZ3ZLmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imcar0TGmKQcV1QI+nrofEUkZxQ6V51u76v35b1wNe/MvdL/hXir I7jpLA3NtNK1rbkD2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NlkBmbR1LS6Kx8w5MHqDEE9+QqC5DKaQeMz5IFBBG6h+L JwsQ/lfo9C1IyTojJ1LBDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfEn1DNQrx9HSayKszvXgSJBUoFIvD3sIcP1fhJPM6B/8fWpU mjvSS3Oqn9LW4VcbnLxZ1H6mbk6k6aQAB9HEpyiJ+dym1L8cD17Js0v4cp1Mn8BzYW5kBfGcQGyP wjy3TzcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
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: Thu, 09 Sep 2021 12:46:53 -0000

On 9/8/2021 11:59 PM, 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)

Picoquic has in fact support for two variants of multipath, draft-liu 
and the single number option draft-huitema-quic-mpath-option-00.

Multipath has not yet been deployed in the picoquic demo program -- all 
tests are on simulated environments. I could easily add a listing of all 
IP addresses available at the client on start, given then a list of 
addresses to choose from, and more or less automatically trying them 
all. I should add a monitoring of this set of addresses using system 
APIs, but those APIs are of course system dependent so that's a bit of 
work. I would be motivated to do that if someone is using the feature...

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

For a discussion, see: 
Both options work. The single number space option is simpler, the only 
problem being the number of ranges in the acknowledgements.

-- Christian Huitema