Re: Multipath (was: Re: Re-chartering for extension work)
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 16 December 2019 15:42 UTC
Return-Path: <mikkelfj@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 E352B1200D7 for <quic@ietfa.amsl.com>; Mon, 16 Dec 2019 07:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Xw51ekPgL_QI for <quic@ietfa.amsl.com>; Mon, 16 Dec 2019 07:42:26 -0800 (PST)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 ABD8E12006D for <quic@ietf.org>; Mon, 16 Dec 2019 07:42:25 -0800 (PST)
Received: by mail-ed1-x52f.google.com with SMTP id dc19so5367903edb.10 for <quic@ietf.org>; Mon, 16 Dec 2019 07:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ky/oIFCryh5dWxeaE/InrzSSTwCwCfFnfsD4+Zcvh+8=; b=rTm4fAmmwPiGhvAfUR3r1W5v4nzmglH8tMhmPDNQq+NVy9iMy2Gix3MSav7pcUAilG /OPpq35331o6jeqsHjtZ+9VXSGTScw8+8haL7am1oBS3bWov2i7/bb7Sc5BsOp54PJ4T ZhbGl77g/4DACxogoEA0jhWdTtWUWNfWXnz9I1iSl44fu96jqGdmog0b3bUMmCuOKfE0 FW393KrzfMhuWKzq0p22ASy/+kQzWIu0wf4N9UL06KuuAEIAymTgXmOMpVwxI5sxLV+W N+Tkq+qBH/n+igI2N1gw3EnfG9NeD2UvPYc1SuHH/mri8bAMWEAg793pYEvGKnuyX2Yh IslQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ky/oIFCryh5dWxeaE/InrzSSTwCwCfFnfsD4+Zcvh+8=; b=bBHv8mDBQV1VHaraTbk+nuymAwQ4zOaqblIXYvoYVqEpvdmSYhW8uTDWP/kzqhme8e i5gbARr9EL2uV8a3ig8AP+gP21g/IdIi1IGXsvz3JH1AyI97WbguZ+XdfLo0Eh2oGTcp zYCXt5RhcXF9n8fB5D1bAPjNQhGq7gU55ppfnvVk/C8ByE8FfCT6SU8eaepo75hVNVs7 GPpxI4XIDOMqL6UGE1j7AK8IKMJg+k+KJZnDixkmAxCzM39opflOnH4i7+igs48hTDWy QNYfA/848OeYTBCUkABoiqzSnJUsN49C1sZD7V2/m206D45aaSjqa0hRRgZ2OgEK+pSF s2gQ==
X-Gm-Message-State: APjAAAX7umExG7Fnre0v8zu6JkO1/PHvQNLijA9yR7BwcOWZUohMLydj 62PrpLbayvRC+0OePiQmTe8YfPEGRA9gTy6HmyQ=
X-Google-Smtp-Source: APXvYqzqVzeMOS2THdCUgnUKc9Y/3uWHVZL5DQa/QI2bqFvdb+vZE1aTxO8JffOOyBa6STVkI0MzgmH6ztKDsph81u0=
X-Received: by 2002:aa7:df89:: with SMTP id b9mr843565edy.99.1576510944209; Mon, 16 Dec 2019 07:42:24 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Dec 2019 10:42:23 -0500
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <49366B32-6425-486C-9453-96D27E2E8EAE@tessares.net>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <1E872371-F543-4822-8C11-05601913A72E@tessares.net> <752D0B90-8B29-4DBC-9B2F-09E834335598@eggert.org> <49366B32-6425-486C-9453-96D27E2E8EAE@tessares.net>
MIME-Version: 1.0
Date: Mon, 16 Dec 2019 10:42:23 -0500
Message-ID: <CAN1APdfNyMBzeWKVRQojo4W_mgxXSSwj4X4EvFC9Pfz4bZ+Pdg@mail.gmail.com>
Subject: Re: Multipath (was: Re: Re-chartering for extension work)
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>, Lars Eggert <lars@eggert.org>
Cc: IETF QUIC WG <quic@ietf.org>, quentin.deconinck@uclouvain.be, Mark Nottingham <mnot@mnot.net>
Content-Type: multipart/alternative; boundary="000000000000d06ff40599d40eed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/yoYwkOXpfC1xoEfJqfOXv0QZXEo>
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: Mon, 16 Dec 2019 15:42:28 -0000
ACK across paths could lead to privacy leaks, no? Mikkel On 16 December 2019 at 13.13.47, Olivier Bonaventure ( olivier.bonaventure@tessares.net) wrote: Lars, > > On 2019-12-13, at 20:05, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: >> Do you have any specific plans for the multipath work ? > > thanks for reminding us about that! There is of course no intention of dropping the multipath work item from the charter. It's already in the charter and will remain there, so it's not affected by this rechartering. > > (One could call multipath an extension and mention it alongside the others in the modification that Mark posted in the first message of this thread. Personally, I see it as a much more fundamental - and difficult - update to the base protocol, and therefore would keep it highlighted in the way it currently is in the charter.) > > I think we'll be ready to start having discussions on multipath in parallel to working on these new extensions; I do expect the multipath work to progress at a slower pace, however. While we don't have to start at zero thanks to MPTCP, We can leverage many of the lessons learned from the design and the deployment of Multipath TCP into MPQUIC. When Multipath TCP started, multipath congestion control was a challenge, this problem has been solved with different coupled congestion control schemes. With Multipath TCP, we had to struggle a lot with middleboxes and how they interfere with TCP and Multipath TCP. QUIC avoids these problems and makes the design more simple and more flexible. There are many problems that exist in MPTCP that disappear in MPQUIC. For example, in MPTCP, data sent over a subflow must still be retransmitted over this subflow even if it has already been acknowledged over another subflow at the data level. With MPQUIC, once data has been acknowledged on a path, it never needs to be retransmitted again. Another example are the selective acknowledgements. In TCP, the length of the (MP)TCP header restrict the number of blocks that they cover. In MPQUIC, we do not need to deal with this problem... > hard challenges remain (e.g., when pooling capacity, can we do it in a way that doesn't leave us operating near the max. RTT of the paths?) With MPQUIC, we are not as constrained as with MPTCP for the transmission of acknowledgements. This means that when pooling capacity it is possible to send acknowledgements on a different path than the one used for the data. This would be difficult in an MPTCP implementation but is easy in MPQUIC. As QUICv1 is now getting stable, it makes sense for the working group to adopt an initial design for multipath QUIC and then improve it. Olivier -- Disclaimer: https://www.tessares.net/mail-disclaimer/ <https://www.tessares.net/mail-disclaimer/>
- Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Jana Iyengar
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Mark Nottingham
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Salz, Rich
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work Mark Nottingham
- Re: Re-chartering for extension work David Schinazi
- Re: Re-chartering for extension work Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Multipath (was: Re: Re-chartering for extension w… Lars Eggert
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Mikkel Fahnøe Jørgensen
- Re: Multipath (was: Re: Re-chartering for extensi… Christian Huitema
- RE: Re-chartering for extension work Mike Bishop
- RE: Re-chartering for extension work Kuhn Nicolas
- Re: Re-chartering for extension work Ian Swett
- Re: [EToSat] Re-chartering for extension work Christian Huitema
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Multipath (was: Re: Re-chartering for extensi… Florin Baboescu
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- RE: Re-chartering for extension work Roni Even (A)
- Re: Multipath (was: Re: Re-chartering for extensi… Ryan Hamilton
- RE: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Jana Iyengar
- RE:(2) Multipath (was: Re: Re-chartering for exte… Madhan Raj Kanagarathinam
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Lars Eggert
- RE: Re-chartering for extension work Roni Even (A)
- RE: Re-chartering for extension work Roni Even (A)
- Re: Re-chartering for extension work Lars Eggert
- Re: Re-chartering for extension work Magnus Westerlund
- RE: Re-chartering for extension work Kuhn Nicolas
- RE: [EToSat] Re-chartering for extension work Kuhn Nicolas
- Re: Multipath Gorry Fairhurst
- Re: Re-chartering for extension work Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Tommy Pauly
- Re: Multipath (was: Re: Re-chartering for extensi… Jana Iyengar
- RE: Multipath (was: Re: Re-chartering for extensi… tim.costello
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Re-chartering for extension work Lubashev, Igor
- Re: Re-chartering for extension work Martin Thomson
- Re: Multipath (was: Re: Re-chartering for extensi… Olivier Bonaventure
- Re: Multipath (was: Re: Re-chartering for extensi… Lucas Pardue
- Re: Re-chartering for extension work Dmitri Tikhonov
- Re: Multipath (was: Re: Re-chartering for extensi… Mirja Kuehlewind
- QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Tommy Pauly
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Eric Rescorla
- Re: QUIC re-chartering: include DNS-over-QUIC? Ted Hardie
- Re: QUIC re-chartering: include DNS-over-QUIC? Jari Arkko
- Re: QUIC re-chartering: include DNS-over-QUIC? Magnus Westerlund
- Re: QUIC re-chartering: include DNS-over-QUIC? Stephen Farrell
- Re: QUIC re-chartering: include DNS-over-QUIC? Christian Huitema
- Re: QUIC re-chartering: include DNS-over-QUIC? Daniel Migault
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Salz, Rich
- Re: QUIC re-chartering: include DNS-over-QUIC? Christopher Wood
- Re: QUIC re-chartering: include DNS-over-QUIC? Ian Swett
- Re: QUIC re-chartering: include DNS-over-QUIC? Vidhi Goel
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Duke
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie
- Re: QUIC re-chartering: include DNS-over-QUIC? Mikkel Fahnøe Jørgensen
- Re: QUIC re-chartering: include DNS-over-QUIC? Lucas Pardue
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Kline
- Re: QUIC re-chartering: include DNS-over-QUIC? Martin Thomson
- Re: QUIC re-chartering: include DNS-over-QUIC? Erik Nygren
- Re: QUIC re-chartering: include DNS-over-QUIC? Paul Vixie