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

Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 01 October 2020 16:58 UTC

Return-Path: <sarikaya2012@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 C1E463A1126 for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 09:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1HMKW9QCiIfb for <quic@ietfa.amsl.com>; Thu, 1 Oct 2020 09:58:43 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 AC42B3A1125 for <quic@ietf.org>; Thu, 1 Oct 2020 09:58:43 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id f70so4523233ybg.13 for <quic@ietf.org>; Thu, 01 Oct 2020 09:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=/LtM7RuRd6Z9bKRtxUV0BvAsFiocOL+FuDCIco5hpps=; b=ZHIPFkj7OUUdtxKhyvRXBs4VOQdjyaKyobs67ioG5ogHsG1g0Kl7Alk+DTS4VDkKSJ QZ5m8HrtEQawHRG3swYk0ZkKvXGdTJEt9LdSSYabT7VlwzwAI6eWG/fvKPjm0EUr4FWo SPYtl1wKGzE4y3+VuXhMpieqbFauaDsbZkclTvRr+KDdii4rdmBmlbw8UZQtFkUJe7h3 TkPoXPNL2fIwPZ3W4cE6z7hBIQPp6P0EOM4k9u3T/gT568z26ljLcsuay04VCFSaCguL 2mVR2punJBL7Z6mgBv6BYDXeU/7DZFzvzi5ImT2o90nND5PeEsA76ufaplOyy5sVoDTQ tYrQ==
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:reply-to :from:date:message-id:subject:to:cc; bh=/LtM7RuRd6Z9bKRtxUV0BvAsFiocOL+FuDCIco5hpps=; b=km0J+8LkyOK7jBtICU7jDb5H0dXRUlHkYddiyHTg3Ai90pkeTra5ulk/2B3dngH5AC d6plnXltoWjbPLLFV1FR380L0jGw6Qphcz+EIffpeYFYPBP8Hb5WcwN8T+Mf6aP+G7lm nqsiHlhkes/DQM9cXy7aaDg1K1ajjn9B1PRKHe+tdTWjTFzYWO1oTpbJ0HCBArrG0rXR N+DCQE2gyXrW+JBhgX/lGWwMG8HuWgU+4aDY9fdtsP6QQG3nlqSZ5+HDNRmxcylJ9FeA MmKOt/i2OoCot7pGzKbEjvyC1MVrj9/bL0gtMRM3WzDoLb590tzbSMNKw+dNrO3udWza fVMw==
X-Gm-Message-State: AOAM53209HkOnIkudfWSnns6v1csAaSOhHOSPBMBfSf1wBm8P9cRaFA8 TG+B2zLdaruDQnfYnvICtmyjJscT9d2EfOgmvM8iw6n5hBo=
X-Google-Smtp-Source: ABdhPJyuiZP9m3HN9FzYrAgeuWrHO6d6E8GJ1/16+s0guEGwsABs0p9+eJlrz8+8UkaDnbbOzJvP+tolWCo0rKvPWOg=
X-Received: by 2002:a5b:b07:: with SMTP id z7mr11324755ybp.318.1601571522883; Thu, 01 Oct 2020 09:58:42 -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> <CAM4esxRYyB3Y19P=0D8qzrGPTwGFWJT2T_eWQsODYrkJahX3Qw@mail.gmail.com> <CAKKJt-dvL3ccbLFDQ0CaS3yJLdQdRgbWZwdeAThB1t1+EQBn7g@mail.gmail.com> <CAKcm_gPoLbYEMx5HE1iBkMsufZoMDXgqzDf-x2RXGODXgW7=aw@mail.gmail.com> <c12c61b5-1720-a1c4-92ed-9cfe2f772c4f@huitema.net> <CAC8QAceYxtxWjZAe046At2_xqFBaCpcxbkXgzameHTFcRP-=pg@mail.gmail.com> <0535637F-BCA0-4449-ACCF-395EF70D2D98@fb.com>
In-Reply-To: <0535637F-BCA0-4449-ACCF-395EF70D2D98@fb.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Thu, 01 Oct 2020 11:58:31 -0500
Message-ID: <CAC8QAcdb56LzedOAJpOWUAApbadDeaWwpPE-fJWBGLDdw+re+Q@mail.gmail.com>
Subject: Re: Preparing for discussion on what to do about the multipath extension milestone
To: Roberto Peon <fenix@fb.com>
Cc: "sarikaya@ieee.org" <sarikaya@ieee.org>, Christian Huitema <huitema@huitema.net>, Matt Joras <matt.joras@gmail.com>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b431fe05b09eed86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/gPFF8biTtvdpIcIFmOJVgxkE7uQ>
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: Thu, 01 Oct 2020 16:58:46 -0000

On Thu, Oct 1, 2020 at 10:28 AM Roberto Peon <fenix@fb.com> wrote:

> I’m probably on the other side of the coin here.
> Were we doing MP, I’d prefer to have a separate packet-space per path,
> because you probably need a separate congestion-controller instance per
> path.
>

me too.

Behcet

> -=R
>
>
>
> *From: *QUIC <quic-bounces@ietf.org> on behalf of Behcet Sarikaya <
> sarikaya2012@gmail.com>
> *Reply-To: *"sarikaya@ieee.org" <sarikaya@ieee.org>
> *Date: *Thursday, October 1, 2020 at 8:04 AM
> *To: *Christian Huitema <huitema@huitema.net>
> *Cc: *Matt Joras <matt.joras@gmail.com>, Olivier Bonaventure <
> Olivier.Bonaventure@uclouvain.be>, Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com>, Ian Swett <ianswett=
> 40google.com@dmarc.ietf.org>, QUIC WG <quic@ietf.org>, Martin Duke <
> martin.h.duke@gmail.com>
> *Subject: *Re: Preparing for discussion on what to do about the multipath
> extension milestone
>
>
>
> Hi Christian,
>
>
>
> What about MPTCP? It would be good to know what MPTCP does in this case?
>
> Also does having a different packet number space create problems, or is it
> just your personal preference?
>
>
>
> Behcet
>
>
>
> On Thu, Oct 1, 2020 at 2:58 AM Christian Huitema <huitema@huitema.net>
> wrote:
>
> I am not sure that the current "mpquic" draft is the right approach.
> Specifically, I do not agree that having one packet number space per path
> is the right approach. This contradicts the design of QUIC V1, in which
> data sent on multiple paths shares a common packet number space. For
> example, in QUIC V1, we can start a connection on one path, migrate to
> another path, and keep the same packet number space throughout. I find that
> a very nice property -- and also an essential property if we want to
> support NAT rebinding. Handling multipath with a single number space
> requires some book-keeping on the sender side to match acknowledgements and
> sending paths, but we have working code for that.
>
> I am also not convinced that we properly understand the concept of "path".
> There is very little in the QUIC V1 protocol that requires transmission
> paths to be symmetric: any packet sent from a node to a valid address of
> the peer will be accepted, provided the crypto works. The linkage such
> requirement comes from the statement that a server starts directing traffic
> to a validated path when it sees the client using the same pair of
> addresses. This is an "implicit" linkage; I would expect that the first
> role of a multipoint extension would be to replace that by an "explicit"
> statement of preferences.
>
> I am worried that we have a set of unresolved security issues around
> paths, largely linked to the requirement to support NAT rebinding. If we
> support NAT, the IP headers must be outside the authentication envelope of
> the crypto. There are plausible attacks in which the attacker splices a
> cryptographically valid packet and a forged IP header. We have some
> defensive heuristics, but if we study multipath I hope we will end up with
> something better.
>
> -- Christian Huitema
>
> On 9/30/2020 5:51 PM, Ian Swett wrote:
>
> Given the responses, can we narrow down the way forward(ideally on a
> different thread) to directions that are less open-ended?  I'll suggest
> some options, but the chairs and/or ADs need to decide.
>
>  1) No future work on multipath in the QUIC WG, in the belief the existing
> connection migration functionality is sufficient.
>
>  2) Adopt the existing draft as a starting point for QUIC multipath(
> draft-deconinck-multipath-quic
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddeconinck-2Dmultipath-2Dquic&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=qRLqBfssWffIVMcb3b7R5gxykJMN9tqDTp7pq9j5QCY&e=>),
> with the explicit goal of not expanding the scope of the document.
>
>  3) Adopting multipath as a core QUIC WG deliverable.
>
>
>
> I favor #2, but these may not be the right options.  Normally I'd say
> people should work this out in person, but that doesn't seem viable at
> the moment.  I'm happy to set up a long(3-4+hr) Google Meet to discuss this
> via videoconference if that helps move the discussion forward.
>
>
>
> Or we can form a design team, which typically takes O(3 months) to finish.
>
>
>
> Ian
>
>
>
> On Wed, Sep 30, 2020 at 3:15 PM Spencer Dawkins at IETF <
> spencerdawkins.ietf@gmail.com> wrote:
>
> Hi, Martin,
>
>
>
> Just a couple of thoughts here:
>
>
>
> On Wed, Sep 30, 2020 at 12:16 PM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
> (Speaking as an individual)
>
>
>
> There is some back-and-forth as to whether these are useful cases are not.
> I'll take it on faith, given the proponents, that there is a real hope of
> deploying this. However, I share the desire to not have the WG fully
> consumed by MP-QUIC for the foreseeable future.
>
>
>
> That sounds right. I'm assuming that getting the core QUIC specifications
> published and doing any cleanup work necessary SHOULD/MUST take priority,
> in the BCP 14 sense of those words.
>
>
>
> As Lars' initial note said, I'd also like to see the manageability,
> applicability, and datagram extension working group drafts, already adopted
> by QUIC, moving forward.
>
>
>
> I don't think the community has well-established solutions for many
> problems in this space (e.g. scheduling). However, I think QUIC is a far
> better platform for experimentation than the alternatives, and would
> support a draft similar to draft-deconinck-multipath-quic
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddeconinck-2Dmultipath-2Dquic&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=qRLqBfssWffIVMcb3b7R5gxykJMN9tqDTp7pq9j5QCY&e=> that
> provided the required protocol extensions to make that happen [1].
>
>
>
> I agree that scheduling is challenging - 3GPP is certainly spending time
> defining different strategies for behaviors, even in addition to the ones
> we described in
> https://datatracker.ietf.org/doc/draft-bonaventure-quic-atsss-overview/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbonaventure-2Dquic-2Datsss-2Doverview_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=yV58k7v0W6KRG-4kJdhZ3Hs461h_EZKSw7VT6VHgsvU&s=79s85o1Msi5birIYHLoQ2DCLdCA8M8KOYgh_gWY81EI&e=>
> .
>
>
>
> And I agree that the QUIC protocol would be a better platform for
> experimentation than anything I can think of (other suggestions are, of
> course, welcome).
>
>
>
> IIUC the hard, unsolved problems are common to all MP protocols, so I
> don't think further research and future standards in this area are specific
> to QUIC or appropriate for the QUIC Working Group. But experimental QUIC
> extensions would accelerate this work, are appropriate for the WG, and may
> get us to a place where we could confidently develop standards about it.
>
>
>
> Targeting Experimental status for work in this area sounds like a fine
> plan to me (much better than not thinking about multicast in the IETF for a
> while longer).
>
>
>
> I know you have a variety of tools at your disposal to direct this work
> (MP-TCP was done in its own working group, for both Experimental and
> Standards-Track versions of the protocol specifications). Do the right
> thing, of course.
>
>
>
> What do you and Magnus need from members of the community, to help move
> forward on this?
>
>
>
> Best,
>
>
>
> Spencer
>
>
>
> Martin Duke
>
>
>
> [1] I would prefer that this draft be Experimental, and have numerous nits
> about the design that are not relevant to this thread.
>
>
>
>
>
>