From nobody Tue Nov 10 06:58:59 2020 Return-Path: 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 C57153A0FCA for ; Tue, 10 Nov 2020 06:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.902 X-Spam-Level: *** X-Spam-Status: No, score=3.902 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, FREEMAIL_REPLY=1, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VWXwNLv0NaEH for ; Tue, 10 Nov 2020 06:58:57 -0800 (PST) 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 788483A0FCE for ; Tue, 10 Nov 2020 06:58:54 -0800 (PST) Received: by mail-yb1-xb33.google.com with SMTP id i193so11909472yba.1 for ; Tue, 10 Nov 2020 06:58:54 -0800 (PST) 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=S9bNETEypbVp156E3bNnNKh0JJSrudNkl74J+tSf2yM=; b=BXkNLgUzbSWSjRzLP6A+27U8yoGimrDU+YevUZfUILJdsIDYjktjHdZaBz1MkPsU8t jbbWZG0uoYoY/Tx4snPkSvXOxA6EJu1XaRhK8Pk8rQ6Ub84z2hWUNmIvTu5pPq0qAZvI adCAIvVBvKjDhpCyijDX0KCYhO1QhdCVny+ERI56MJtXQ0uo0ICzuWiAt5zekT40yYA2 gx1QOI8jy3ZbM0jmZYyTMKAL1ZQxTvWJOvaw0yrXTnbwYSvcpkmM+nyj3Dh+dISiETtC 6WHN44k6NdevCQSi7Lw8C7FYiqy84zYlsCW2b4KAwipw+MsrnwN/tRctnrDVt4OWvU3g uUmg== 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=S9bNETEypbVp156E3bNnNKh0JJSrudNkl74J+tSf2yM=; b=kRsuxW6l1hGofeWddAwqXZPYgaqgQTu+zOVHkPD4Vl/n6OayT3JzQvlX9AVHjSvMzV 2XwHy00ZopEr87SNgiXPdi3sI9Vvrvz+qPUo7oAvC+c0nEJJ0Zuvl2WJ0jRUmzJMTjcr AfEuN85f8CunHts69Nfo96wXdzlMB17s3qOGnhsqujOT+o5Ngk8dfHtWm8QGltmrh2GB mh4QW6IKeh0wkwbuoAWKERxsmJ+AWP//tn2EWLBGKB4wWggG55rLFJGIj3DMtqoD7Ay+ hN8FhFkXlljAMWQsOuwPCYfyNhS20DjSN8S6n7CQ9MKjbehd71Igfks5RvYM91lmfRLi 5a4w== X-Gm-Message-State: AOAM532kO2pg+PDfF6qFY8Qls/jLPuauL9O290W2Vs6Bb03lbL5T7rvx SOwpo7QVPj2a+u8ZUm1EPR18Xj1aU1/mj4CaffqMkvh310E= X-Google-Smtp-Source: ABdhPJzWwnItKcjrlO6LBYwrXyxnNbDhRp1hfOAHdtzZFfWQBdlFIU/qNewHH8e4SmeAqhZZZOTq1YTmvdIff7qt9aQ= X-Received: by 2002:a25:c042:: with SMTP id c63mr27077106ybf.465.1605020333666; Tue, 10 Nov 2020 06:58:53 -0800 (PST) MIME-Version: 1.0 References: <8bf17aeb-2545-4b8a-24bd-a495a38bda9d@huitema.net> <7931447A-E557-4B7E-8256-BD6004F29CBF@fb.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 10 Nov 2020 08:58:27 -0600 Message-ID: Subject: Re: What to do about multipath in QUIC To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Kazuho Oku , Roberto Peon , "sarikaya@ieee.org" , Christian Huitema , Lucas Pardue , Olivier Bonaventure , QUIC WG Content-Type: multipart/alternative; boundary="000000000000d8751b05b3c1eaec" Archived-At: X-BeenThere: quic@ietf.org 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: Tue, 10 Nov 2020 14:58:59 -0000 --000000000000d8751b05b3c1eaec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Mikkel, On Tue, Nov 10, 2020 at 8:41 AM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > > On 10 November 2020 at 15.32.52, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2. Switching between multiple paths to serve one stream. > > In this case, connection migration of QUIC v1 is sufficient. > > > This only works for the client. It doesn=E2=80=99t work server P2P. > > I=E2=80=99m alson concerned with how fast it is possible to make the swit= ch in > latency critical operations. Perhaps it can be done fast once, but then y= ou > have to wait. > One of the things I tool away from the multipath virtual interim was that I had, and possibly other people had, the notion that "connection migration" was a heavyweight operation (think, "failover to standby path"), but people were saying that I should be thinking of it as lightweight ("once you've validated two or more paths, you can just start sending on another path"). ISTM that "how fast it is possible to make the switch" would be the sum of 1. How fast you can open and validate another connection - but this could happen before you need to use it 2. How fast you can send the first packet on another connection - my understanding is that you can just do that 3. How you can ramp up the sending rate on another connection to roughly what you had achieved on the first connection - but is that critical for latency critical operations? Are you thinking of other factors I'm missing here? Best, Spencer --000000000000d8751b05b3c1eaec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Mikkel,

On Tue, Nov 10, 2020 at 8:41 A= M Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:


On 10 November 2020 at 15.32.52, Kazuh= o Oku (kazuhooku@g= mail.com) wrote:

2. Switching between mu= ltiple paths to serve one stream.

In this case, connection migration of QUIC v1 = is sufficient.

This only works= for the client. It doesn=E2=80=99t work server P2P.
=C2=A0
I=E2=80=99m alson concerned with how fast it is possible to= make the switch in latency critical operations. Perhaps it can be done fas= t once, but then you have to wait.

<= /div>
One of the things I tool away from the multipath virtual interim = was that I had, and possibly other people had, the notion that "connec= tion migration" was a heavyweight operation (think, "failover to = standby path"), but people were saying that I should be thinking of it= as lightweight ("once you've validated two or more paths, you can= just start sending on another path").

ISTM t= hat "how fast it is possible to make the switch" would be the sum= of=C2=A0
  1. How fast you can open and validate another conn= ection - but this could happen before you need to use it
  2. =C2=A0How = fast you can send the first packet on another connection - my understanding= is that you can just do that
  3. How you can ramp up the sending rate = on another connection to roughly what you had achieved on the first connect= ion - but is that critical for latency critical operations?
A= re you thinking of other factors I'm missing here?

=
Best,

Spencer
--000000000000d8751b05b3c1eaec--