Re: Multipath QUIC prototypes

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 10 September 2021 16:16 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE633A096E for <quic@ietfa.amsl.com>; Fri, 10 Sep 2021 09:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNmZl8VPMkpA for <quic@ietfa.amsl.com>; Fri, 10 Sep 2021 09:16:47 -0700 (PDT)
Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964D43A0963 for <quic@ietf.org>; Fri, 10 Sep 2021 09:16:45 -0700 (PDT)
Received: by mail-yb1-f178.google.com with SMTP id c6so4901495ybm.10 for <quic@ietf.org>; Fri, 10 Sep 2021 09:16:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SL+ugKBgGSfHGkQ7nmx5BAmysaVuxyegn1Uv2jQyLPA=; b=na5g3lXKI9dpyFqgpjBeZskPfGM059jQfelKGGRPdPcRTBXx8sWSWNCRK5pVNSPv19 wHlIU0pnXFihgxKnZ8+0ZzGCi21XztPzeix40YDe3iGls2udQSbs9qAaO9h84nMMlEbe yoL3Lkhl2H1hQNz5Qi+gisQXOcAoEBB2tjj4XU26Tb+rhYgkFj4hZrZhEqLkQYZ771RF UnAmoROBnYwrL7IQXUy1N71MP12Cl+m7gwIpaskCHoy/bkZ69CfqZKPshpw4LJTPDw9j PEKf27/x1kgV/Hzlgqje/f4XI1NPshO3KEfZrCkq5LEufwxGhKDehlF0rLL3tauxzxSv /Nmw==
X-Gm-Message-State: AOAM531UoC8UUsxNGA1payF5Ji77veXXFD9gcwftNQcsMjMlfPZDAbNQ RoF9/RslP/nCqxxSNd3KObzvI+im9Eqg0rDrN0B7V4i9
X-Google-Smtp-Source: ABdhPJx2sIHPMtpw5FR0vbsyep9bxnV6ytY5KJ4782mpH+mcCUmPYYCaw63TtxuZ0+7Oz0H5KSwxHnl6KmjMJckQ1Mw=
X-Received: by 2002:a25:804:: with SMTP id 4mr11497138ybi.346.1631290603910; Fri, 10 Sep 2021 09:16:43 -0700 (PDT)
MIME-Version: 1.0
References: <2a583307-7acc-323b-202b-1c500a63d358@ericsson.com>
In-Reply-To: <2a583307-7acc-323b-202b-1c500a63d358@ericsson.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 10 Sep 2021 12:16:34 -0400
Message-ID: <CAMm+LwgGdf8=P_BYQkvn203yePF2bDVZKv=KMg1PHi2VmeSkXg@mail.gmail.com>
Subject: Re: Multipath QUIC prototypes
To: Michael Eriksson <michael.eriksson=40ericsson.com@dmarc.ietf.org>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f9a1fe05cba6707c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/WErkRkTkfnSKDEQtKikSKKtBoAo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2021 16:17:01 -0000

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=
40ericsson.com@dmarc.ietf.org> 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
>