Re: My BoF report: multipath
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 23 October 2020 03:18 UTC
Return-Path: <spencerdawkins.ietf@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 83C983A110F for <quic@ietfa.amsl.com>; Thu, 22 Oct 2020 20:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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: 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 p5m6YroTvEy1 for <quic@ietfa.amsl.com>; Thu, 22 Oct 2020 20:18:10 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 42B9C3A110C for <quic@ietf.org>; Thu, 22 Oct 2020 20:18:10 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id f140so5564ybg.3 for <quic@ietf.org>; Thu, 22 Oct 2020 20:18:10 -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=M+6RwUc99HOCf3NVgeNVESr4B282uFtk0jNRbYi2ruY=; b=r7I0MzJGdCjMh31WO9mCxz4c1CG/wctyetcpppY7jS5QqRwnJoDmezml2sCF504XOM TnsctxdQkSmWXuEtIbz+PBox1QK2k9huQCaUM6XEAtLhLqe5o51MH7mZ0Nh9Ns2U5dje nfch23MqEP0MrhBEuzVVkipqSCgqWuOs48RUsO2jBeddM0NO5JOlLgNt5V1yuk/pfJTc fplChD1NfLKefjOGd7n/UnFH4P4ry6LTTEiKgrPDE5gLrA28Qfy2kFcerqEwW4ViNAwS 19bLZnVepINr1bSFfrTOtrafinmXlY9EKPtK1kVNiKZSrklg/pZOpP0lU9wpqeCadyPp MDEQ==
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=M+6RwUc99HOCf3NVgeNVESr4B282uFtk0jNRbYi2ruY=; b=a8pbFzowVhdF8K50ifTcWW3BpokNnW20Tvwx/JjV+S3qEMoFdLo37aulbOgDZA0WC3 gW19YjXFHQphWcalgPfCXJef69O72ICGS7SNhXp2GkUHLf/wpcRCOpWyjOAQHmaZ8NFE 0Ss7VfUtRtsEil2/gfkwbN9egTuTiiqJRJ5p/21LMvT1Me/ELqodMldgInqXLN5rRBfD bWedaUzhOnkirwZPGCCUi8vY6/MWtS2rB3WmDt/Rkvwq70IxK7WULyyoP3o1t/mxnoBM NzWMnJXKWmbuoSDN19Ktc7+sueX0p31ZN4BbCbV1tqnaG0h7fgZKovKeB/YDQ28h6dHV ydjQ==
X-Gm-Message-State: AOAM530N2oe8a/1VRlq32v0IFU7BfczSHe+Je1f8Zo28RlnyTjKbXZS6 zuidgFOyt1uU7xJjn9ssaa5s+39xokdh6V589Kfc27x1
X-Google-Smtp-Source: ABdhPJwzMcvbWcr6Vuy+ijm4MQiOYg2SXYBHmS1yu7SqCIkqjnBD49fCnU2/xYZS19oFW6IQ7mbWKLdzqaMY8RZ2QdE=
X-Received: by 2002:a25:4e43:: with SMTP id c64mr556473ybb.380.1603423089415; Thu, 22 Oct 2020 20:18:09 -0700 (PDT)
MIME-Version: 1.0
References: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com>
In-Reply-To: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 22 Oct 2020 22:17:57 -0500
Message-ID: <CAKKJt-d7iQG-5BsTjR+xKLNt_Ru+h_XpDuaO3JgtAx7+Z3_S0A@mail.gmail.com>
Subject: Re: My BoF report: multipath
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ab58d305b24e07d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aYaAHzpkj0W0hDhNMxJFyTDbLFo>
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, 23 Oct 2020 03:18:13 -0000
Hi, Martin, Thanks for this. I have a question and a couple of comments. On Thu, Oct 22, 2020, 19:06 Martin Thomson <mt@lowentropy.net> wrote: > (I put a variation of this comment in the meeting and in slack, but I > wanted to expand on it some. Sorry, but this got long. Four hours is not > enough sleep.) > > Multipath seems pretty clearly useful for certain cases. I think that the > meeting today answered at least the first two of the BoF questions I posed > earlier on the list. So if we are to regard this as a BoF, it meet its > goals (thanks chairs). There is some uncertainty about the first question > about having a clear problem to solve, but I am of the view that we could > muddle through with some combination of either ignoring our differences or > working around them. The third question regarding constituency is where I > didn't find a satisfactory answer. I want to be clear though, this is no > fault of the proponents. At the current time, I am convinced that formally > starting work on multipath would be unwise. > I've been assuming that targeting Experimental would allow people who care about multipath to work on it as part of the QUIC community without derailing needed standards-track work, rather than working in isolation or in a splinter group. At a minimum, the chairs could give priority to needed standards-track work when that's required to make progress. Does that make sense? Multipath aims to improve performance either through latency, robustness, > or throughput. Application awareness and involvement in scheduling seemed > to be the key factor that enables finding the optimal usage pattern or > scheduling algorithm that allow multipath to deliver on those goals. > Applications and users are in the best place to balance goals against other > factors like cost or whatever else matters most. (For reference, I recall > the same point being made by Roberto and Christian most clearly, but > several others made the same point.) Christoph did a good job of showing > how this applies to very specific use cases, and I thought I saw that in > the Alibaba presentation also, but we didn't quite get enough time to get > the necessary detail in either presentation. One potential advantage in > this regard is that QUIC implementations are often closer to applications, > so they might be in a good position to integrate better. > One of the things I came away with today was an appreciation for at least two kinds of applications - the kind that can do better if they handle multiple paths themselves because the details of the application matters so much, and the kind that don't care as much about - if you're using multiple paths simultaneously just to make use of all your bandwidth, that's a lot easier to delegate to a general purpose transport mechanism. However, many of the cases that were presented were exactly the sorts of > opaque intermediation that is almost the antithesis of that ideal. > Similarly, David's assertion that multipath is orthogonal to MASQUE is > reliant on the assumption that application involvement is not that > important. In these cases, it's not clear that using multipath is strictly > good. > > I should unpack that a little. For those people who are making scheduling > decisions outside of the endpoint (possible examples being the satellite > case and the 3GPP case), it's not clear that this is anything endpoints can > prevent. An endpoint probably can't stop a network provider from using > ECMP either. Similarly, it is not clear how an application endpoint could > be aware of these decisions at a level that would allow them to understand > and adapt to this treatment. The result is that these cases have a far > more ambiguous value proposition. Improvements come with trade-offs: for > instance, the application might get better throughput, but it comes at a > cost to latency. So I conclude that while these intermediary-based designs > might provide an aggregate gain, they will probably not realize the full > performance gains that come from end-to-end awareness and control. > > For IETF insiders, see also the BANANA or LOOPS BoFs which were strictly > network-based analogues of these. Many of the same concerns that caused > those BoFs to fail apply to those use cases. > > Maybe we accept the application of the protocol to these questionable ends > as acceptable collateral if we are able to deploy at the endpoints. Maybe > we allow intermediaries to seek marginal improvements, but try to ensure > that we have a clear path to deploying something better in the long term. > But there is a risk that deployment in the network could interact poorly > with more-ideal end-to-end solutions and even prevent those deployments. > ISTM that this is extremely helpful observation. The presentation I gave talked about short-term synergy (can't do multipath QUIC without a QUIC stack, right?), but you're raising a really important question about opt-in and bypass for intermediaries, that people who care about intermediaries should be thinking about. At a minimum, transparent interception for QUIC intermediaries will be a lot harder than it was for TCP intermediaries ... These are systems-level questions that are large in scope and subtle in > their effect. I think that it will require considerable energy to resolve > them. Or, as seems more likely in my experience, it will take more time > and effort to design a protocol where there are fundamental disagreements > about the nature of the deployment models. > > However, this isn't the only factor. We are not deciding on the merits > and value of multipath in a vacuum. It was pretty clear that multipath has > potential, at least in principle, or in certain cases. I'm also mostly > convinced now that we could produce a design. There's some uncertainty, > but it seems like we could tolerate that. QUIC definitely wasn't a sure > thing when we started out, I can't expect any large effort to be risk free. > > So, with some uncertainty about uses cases, I might still conclude that we > have satisfactory answers to the first two BoF questions. My concern here > is about the third: constituency. > > What I think is most important at this point is understanding if this > protocol will remain a single, coherent thing. That we can keep building > on the "synergies" that Spencer referred to. No matter the technical > merits of the protocol (it's great! probably!) that synergy is probably the > most important feature that this working group has delivered with QUIC. > The details of the protocol matter less than the fact that we have a group > of people committed to building and maintaining that protocol. This > working group needs to be the venue where work happens so that this > community can continue to build on this success. > > So for multipath, if we take it on, I'd only like to do so if I was > convinced that a non-trivial proportion of the active deployments are > committed to working on it and deploying the new extension or version. > That is, that this community wants to do the work. I see no evidence of > that yet, which is why I will claim that this fails to satisfactorily > answer that third BoF question. > > It is very easy for a splinter group to define a new version of QUIC that > does anything. draft-deconnick or draft-huitema could be the basis of that > sort of effort and that could result in the definition of QUIC 84 or > 0x0219c81 or whatever. Call it QUICv2 if you really want. But if that > protocol is only used in certain narrow contexts, then it doesn't produce > any of those synergies. On the contrary, it works to undermine them, so I > would prefer to avoid that. > > So rather than ask whether multipath is doable, I think we need to instead > decide what the QUIC working group - the group that built the core protocol > - is doing next for that core protocol and the deployments that depend on > it. Personally, I don't think that we're ready for another large project. > We need deployment experience with the protocol. We also need to go in and > backfill those pieces of QUIC we need for the next thing, like version > negotiation. For me, that's more than enough. > > I've now seen a lot of enthusiasm for the idea of multipath. There were > some great presentations with convincing use cases. There might be too > much diversity in use cases or a schism in approaches, but we probably > could, with sufficient energy, overcome that. However, I have to conclude > that this is not a good time for starting that work. > > I realize that this is likely unsatisfactory to those who want multipath. > I also recognize that deferring work when there is such clear demand could > result in that demand manifesting in a bunch of non-interoperable > protocols. Those are risks that we each have to assess for ourselves. > > This will change over time. I don't know how long it will take. But it's > not now. > > Thanks for reading this far, > Martin > >
- My BoF report: multipath Martin Thomson
- Re: My BoF report: multipath Christian Huitema
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Olivier Bonaventure
- Re: My BoF report: multipath Christian Huitema
- RE: My BoF report: multipath Flinck, Hannu (Nokia - FI/Espoo)
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Spencer Dawkins at IETF
- Re: My BoF report: multipath Behcet Sarikaya
- Re: My BoF report: multipath Lucas Pardue
- Re: My BoF report: multipath Roland Zink
- Privacy considerations of multipath (Re: My BoF r… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Roland Zink
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Christian Huitema
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue
- Re: My BoF report: multipath Jana Iyengar
- Re: Privacy considerations of multipath (Re: My B… Eric Kinnear
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Mirja Kuehlewind
- Re: Privacy considerations of multipath (Re: My B… Behcet Sarikaya
- Re: Privacy considerations of multipath (Re: My B… Ian Swett
- Re: Privacy considerations of multipath (Re: My B… Spencer Dawkins at IETF
- Re: Privacy considerations of multipath (Re: My B… Lucas Pardue