Re: Multipath (was: Re: Re-chartering for extension work)
Lucas Pardue <lucaspardue.24.7@gmail.com> Fri, 10 January 2020 11:39 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 8FF9F1208AB for <quic@ietfa.amsl.com>; Fri, 10 Jan 2020 03:39:29 -0800 (PST)
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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Gb5oru-5o6OP for <quic@ietfa.amsl.com>; Fri, 10 Jan 2020 03:39:28 -0800 (PST)
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 BA822120024 for <quic@ietf.org>; Fri, 10 Jan 2020 03:39:27 -0800 (PST)
Received: by mail-ua1-x92a.google.com with SMTP id c14so581240uaq.11 for <quic@ietf.org>; Fri, 10 Jan 2020 03:39:27 -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=pe9qYCiq9ONPTgJazuBGPgzFMKe1KFkxoVkGJYu2pSE=; b=nsdRunNcIhpCn4rBGZR4S9nRieNTW4lCH45jnEdytwMzxB/q6aZ//ABAtkTO4pYCu4 4nCzoOUhj4oJqRzb2G9q7JgScjfCyHWDZRGSvi5fxvRAaj5mDNPosTV2CQ1hT+nYTr+S bYjCPaUm0CzCVYb7ICqV5u74wDIvqVE5etuKLzxz/rIEr6N//HXWwngDxd63gGDf3Cd4 hyPqvQoeRlcU7eQvXui2kEzA3L+u3w8Yl2yVhp9zz2x+0TG9hjVYKcO8QH9DHusCGSXL DU5AX0HtJOL/agnkZ4GvllaLLBEbfEpdm/HDOQGFaP8wlnEGeXnARKm4zgb5Rv5bpHZd ChBg==
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=pe9qYCiq9ONPTgJazuBGPgzFMKe1KFkxoVkGJYu2pSE=; b=J3zsOHBGhzm+wvJapSsT0pwPjRU2975UVFluK7gf5w08+SnrYBCORV2++nK5elMsgE sfdhOshnoJgBr1i6YBIVq/rpiOhcY0mLASOdk7mdJmTdS68QC6A7eALuKoC2KBsEyF96 HUK9JZXcIpVw1LXzJpINcQL5+T2Vu/BQyyBgg7jaadsq+fSX+N462a8o4U7xrcvg2xud h2ZQxLAh03s5pzab+/sHshIwB96iGN8t9XKLpfS0/I5yYSm2c4KPtKmd0aRFz0/H5jgY wiHY4SeNsumDOPrdNkSwXY6FTSisqPRlpPCohdH+kWyy/5D3Eil/SVIpuSm/WdbeN7Hm t2nQ==
X-Gm-Message-State: APjAAAUypJbx1Hn0plizXx2b1VaL16kWcxl2LYexOFxGurjK/TjuNfu1 dyEQ7Iz4N+tdoEQ3WuJcFWVTRdW8d/KOPUGQ8aU=
X-Google-Smtp-Source: APXvYqxMlCZ0r96Yt3PduTJKuqAvHtyT5FTq/1hzkxBwuesiJ8cfrfwkb9CorY8MJpO+mG41XheOpUiRSwOOQopDqh8=
X-Received: by 2002:ab0:71da:: with SMTP id n26mr1593432uao.102.1578656366771; Fri, 10 Jan 2020 03:39:26 -0800 (PST)
MIME-Version: 1.0
References: <D9AB44F9-8EBA-42F7-957F-69622C0681CE@tessares.net> <8EC91F90-2799-48EF-B083-D9C32F2D28F0@apple.com> <CACpbDcdsauAPDT0a_oqsMX1Dg+B8z61iAfurV1KwQwsUifGMcg@mail.gmail.com> <148DA586-6EDF-4DBE-9CB0-685C66745A7C@ericsson.com> <3A7DF177-3C7B-45AE-8677-BA1D0DC84A74@tessares.net>
In-Reply-To: <3A7DF177-3C7B-45AE-8677-BA1D0DC84A74@tessares.net>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Fri, 10 Jan 2020 11:39:15 +0000
Message-ID: <CALGR9oZzAa3SuoXgtbq=sdv5Jd6_dM4UTG7biM+euOEmorViKA@mail.gmail.com>
Subject: Re: Multipath (was: Re: Re-chartering for extension work)
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Quentin De Coninck <quentin.deconinck@uclouvain.be>, Jana Iyengar <jri.ietf@gmail.com>, Ryan Hamilton <rch@google.com>, Mark Nottingham <mnot@mnot.net>, Christian Huitema <huitema@huitema.net>, Lars Eggert <lars@eggert.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, Tommy Pauly <tpauly@apple.com>
Content-Type: multipart/alternative; boundary="000000000000f6c1aa059bc7939c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/OlwAHMyK2mAuRCRuCP-Lpyb7ntA>
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, 10 Jan 2020 11:39:30 -0000
Hi Oliver, all, Taking a very brief look over the 03 draft, if I grokked it properly I have an observation that may be interesting in the broader thinking about extending QUIC. In draft-deconinck-quic-multipath-03 [1] it states that because there are new path-related IDs, some frames need to be modified and then lists them: NEW_CONNECTION_ID, RETIRE_CONNECTION_ID and ACK. IIUC this would keep the type value but modify the frame contents. My model of thinking has been to assume that frame definitions are immutable, and that extensions that require tweaks to frames would define new ones. For example, draft-huitema-quic-1wd-00 [2] proposes a timestamped ack and so requires a "Time Stamp" field in the ACK frame. It does so by defining two new ACK frame types (vanilla, and one to contain ECN marking). So my observation is not about the proposals themselves but about the composability of extensions. Say for example someone wanted to combine mpquic with 1wd, would they modify the ACK frame or define a new one? >From an implementation perspective, making frame parsing condition on connection-level characteristics such as extensions seems like a bad idea. Frame types are cheap so lets use them. [1] https://tools.ietf.org/html/draft-deconinck-quic-multipath-03 [2] https://tools.ietf.org/html/draft-huitema-quic-1wd-00 On Fri, Jan 10, 2020 at 9:51 AM Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Dear Mirja, > > > As Tommy said, migration is already the first half of multipath support > for QUIC. So I expect it will be easier to add it to QUIC than it was for > TCP. > > > The main benefit of QUIC is that we do not need to take middleboxes into > account and can reason about the transport layer directly. > > I would at least be curious to spend some time on figuring out how much > (or how less) effort it would be. Maybe there is also another step before > going to full multipath support that could support the handover use case > better, e.g. sending redundant data on multi paths or something. I think it > worth think about it. > > > > Please don’t do that. With QUIC, have a unique opportunity to design an > architecturally clean and easily deployable multipath transport protocol. > We should not pollute this design with hacks and short term solutions that > have been included in too many Internet protocols for various reasons. > > However, while I would like to see this discussion starting now, I think > it’s fine to wait for adoption of any draft until v1 is done. > > > As already explained in previous emails, Quentin De Coninck has leveraged > all the lessons learned from Multipath TCP in a Multipath QUIC design that > has evolved in parallel with the standardisation work of QUIC v1. The > initial design was described in > > https://multipath-quic.org/conext17-deconinck.pdf and in > https://www.ietf.org/archive/id/draft-deconinck-multipath-quic-00.txt > > There was a running implementation on top of quic-go that is available > from https://multipath-quic..org <https://multipath-quic.org> > > The draft has evolved several times on > https://datatracker.ietf.org/doc/draft-deconinck-quic-multipath/ > > The recent draft has been implemented on top of picoquic and was released > on pquic.org > > Quentin has studied these designs in details with many experiments, both > in the lab and in the wild on smartphones. He’d be ready to present this in > details to the working group if if eventually decides to work on the > multipath item of its charter. I would encourage the working group members > to start to read the last version of Quentin’s draft and provide comments. > > > Best regards, > > > Olivier > > > ------------------------------ > > 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