Re: Preparing for discussion on what to do about the multipath extension milestone

Lucas Pardue <lucaspardue.24.7@gmail.com> Sun, 04 October 2020 23:33 UTC

Return-Path: <lucaspardue.24.7@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 1F64D3A0A97 for <quic@ietfa.amsl.com>; Sun, 4 Oct 2020 16:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 n6X1sLQkJdey for <quic@ietfa.amsl.com>; Sun, 4 Oct 2020 16:33:29 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 AF6E53A0A8F for <quic@ietf.org>; Sun, 4 Oct 2020 16:33:28 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id e22so2465084ejr.4 for <quic@ietf.org>; Sun, 04 Oct 2020 16:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oNpPfSjqoLIQmAcMp7uTVYw1xqQ9dS4w4pPcBbnwlVQ=; b=kho3n/4MRwaRzR+5HvwzE90qZ1YacnnRgJ7uyWojjkK4Hlck8pzNN+DLn1nMB+TWSK qbNOch/LWh2rI3mMrj/Szejaq1O+7FNh8Qgk8b1bUmKGV71e62e/YiNRmJ5JYGyejvm/ oefw9cgbv1tI8fixwg/l0AXV3oZ/pI0BQBZSlKWwn17cvj/bLpDjN4Vapor8LLLpuk+a IlXSfBovcUMkXfj+GcOGnLlhm48oijxvYkeTlz35RBwXDB/3sCX6na65woMhOeaLPSaM I9AEC5WI7gjT2HMdkK2M0K5LWP87oIYIXMx1iE9IbHITDB1mkZsc75NRUQ8+eSQbqz/V Busw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oNpPfSjqoLIQmAcMp7uTVYw1xqQ9dS4w4pPcBbnwlVQ=; b=gxDpQog/MtI2Sdt1AhlvhoLyLPlmPC7Gk76A7UmR9/Qx4wgLQEmTJEE6FFI08MiIHx LAPQnNR6iMTkareGWn5Y7zol4mm0xHLIgtREtlejrmOmpkrHx1IPPJwhn/FLQQN9Tcjg 2smfxm4VFZso1yi3xcNVjgBDwUfBq9g05p9JzQZ+lCtcGH1EuszPSkQJ0r4Bz6Eswz2M lLFkTPTKsgSSXG0VlNJ+I6j5SPRFRPGj7PRSMTip1AuVfKXMvy7DBrB8jiLeGGXabu0H UIXtwxNDd5ifTyeMOUhAoRP11yxNxE6x9Hfnv8Pvkl9ZBgZ/8Aw+FfRjnjF2UkY8lcWn N4lg==
X-Gm-Message-State: AOAM5303uGXIkKl/ztRlPMOSaWpEx+BHwjch7daLq+tr9hA1e/26+RxQ X4OMz7MJruuFSPIjcv5JOf6O2mzg26wcIixpSK4=
X-Google-Smtp-Source: ABdhPJwimtOy6gzgwglp7UoJreKvLc4B1ryTzYpg2U7CZvub/9nJaJTLs01pX8Zo0g29d4ORK9B4ufF4zZ0qw/hsVeQ=
X-Received: by 2002:a17:906:f2d2:: with SMTP id gz18mr11003394ejb.542.1601854407021; Sun, 04 Oct 2020 16:33:27 -0700 (PDT)
MIME-Version: 1.0
References: <F0A5E38D-4117-4729-BFF8-72D97CAA9908@eggert.org> <CAKKJt-e=+XLZhNWqaG9YSLTRqyQRvDc-dagUSkFwHOByFwZ++Q@mail.gmail.com> <78651438-2fce-ba67-4f44-4228bbc79a75@uclouvain.be> <CADdTf+hOACZ1x=d8SV-aX0f3vc+_fyqTziRqi5gi+nJgppaz8A@mail.gmail.com> <CAKcm_gNF=0gwrPt=Mr1P=dF_-wmXfz-OJkavFSDe1qrXFeMa4A@mail.gmail.com> <20201002164854.GA2124@MacBook-Pro.local> <CADdTf+heu4DGT8PsF0yL1cknTCB0CiHJ_jBwXZ86ccxL6740qA@mail.gmail.com> <CALGR9ob39AhBQq5kt1tsBp6b3EHy8Aq-PkT_tSX3_hM-u9kYnQ@mail.gmail.com> <20201002232028.GG2124@MacBook-Pro.local> <432d19ff-d441-493e-57e7-03df6ce8a848@uclouvain.be>
In-Reply-To: <432d19ff-d441-493e-57e7-03df6ce8a848@uclouvain.be>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Mon, 05 Oct 2020 00:32:42 +0100
Message-ID: <CALGR9oZ7=dy5NnPgKcL5OjC+6_h_Vta+1K1QXmyCDqmX-roTPg@mail.gmail.com>
Subject: Re: Preparing for discussion on what to do about the multipath extension milestone
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: Christoph Paasch <cpaasch@apple.com>, Matt Joras <matt.joras@gmail.com>, QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e998b705b0e0ca1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/WhLW4Y5OPe5KEsfFRiguEFPlJBs>
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: Sun, 04 Oct 2020 23:33:30 -0000

Olivier,

Many thanks for these resources. I'm slowly reading and digesting.
Quentin's Thesis I think has some good discussion about consideration
factors for an MP-QUIC abstract design, such as consideration of path
validation etc. I don't know if uniflow is the correct design but it
definitely helps to understand the motivation for it.

MP-QUIC appears to offer some things that conventional QUIC might not be
able to do*. But it, to me, also presents some problems that don't exist
today. As an individual commenter, not having an in-band signal for uniflow
prioritisation gives me cause for concern. If I were to deploy an MP-QUIC
general-purpose server, I don't have much confidence that I could meet the
use cases that clients want.

Cheers
Lucas

* Spencer occasionally mentions muticast in this thread, which I think is
the autocorrect kicking in. But it's mention is relevant because the
asymmetry of uniflows, and separation of data and control channels could
solve some of the problems that draft-pardue-quic-http-mcast goes to length
to design around.