Re: QUIC - Our schedule and scope

Christian Huitema <huitema@huitema.net> Sun, 29 October 2017 12:35 UTC

Return-Path: <huitema@huitema.net>
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 D66AC13FD62 for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 05:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E7OIie2Qutoj for <quic@ietfa.amsl.com>; Sun, 29 Oct 2017 05:35:45 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E7B13F48D for <quic@ietf.org>; Sun, 29 Oct 2017 05:35:44 -0700 (PDT)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1e8moX-0005K9-4b for quic@ietf.org; Sun, 29 Oct 2017 13:35:42 +0100
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1e8moS-0002Te-EC for quic@ietf.org; Sun, 29 Oct 2017 08:35:40 -0400
Received: (qmail 15085 invoked from network); 29 Oct 2017 12:35:34 -0000
Received: from unknown (HELO [172.30.8.11]) (Authenticated-user:_huitema@huitema.net@[83.110.18.56]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <spencerdawkins.ietf@gmail.com>; 29 Oct 2017 12:35:34 -0000
To: "Eggert, Lars" <lars@netapp.com>, Simon Pietro Romano <spromano@unina.it>
References: <BCAD8B83-11F7-4D4A-B7B3-FCBF8B45CBB4@mnot.net> <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <FAE9A7F7-C642-4AC5-B469-91BE7189F2F0@unina.it> <FFBE48EA-FD6F-42C6-B1A4-80C4CD8D9864@netapp.com> <C0A9C95B-1F30-4167-8943-EAB373F49B82@unina.it> <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, Mark Nottingham <mnot@mnot.net>, QUIC WG <quic@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <4d867d88-12c4-1629-a766-c4b4984bf73f@huitema.net>
Date: Sun, 29 Oct 2017 05:35:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="lHPURVLIPspfqAmnjfBxpE69m4O8MoNTp"
Subject: Re: QUIC - Our schedule and scope
X-Originating-IP: 168.144.250.215
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5je/4L+6mKtyxfUxlPmI88EXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fskaiXrBVQ334ehSs2QpY88B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYc8zYOZy1SS6ohN09nxrcu5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+OlqTWdUBHTyoJG+mqGBYi8bWhnKPmUW/oWx9V3wTBfG4Y+ZnfomCI+rgOtA8u12EwuwjY+ quNh23liqqeOwMwwqy4lE5s79uoGaeHjfOqnzPcqs5RcLqZ0NIAm9sCHr2eyNIkhDia+jiI1x+25 WhJqOf3+cMSJJ9Vk8Y6lSpImWOFtQUIkkMAnR5eEArf6zd8XhA0UizXQaOxPdjju+1r1qq9IJIue NdZ12JJe7t4cD3McN6qoXPjenLhIOF1oeRYYaUQ6nbKS9Ik+txsc3YPtwSyQd76LvsiWbyPh2PwK 2KlWGv3esfm0EuJEorvoTUf+T9qKOv0z7nCHc/5d+MbcfJlbZZh01urflxdd2g4lVOY9YUFS+gfc BkEmyHl54sn3Y80OmAux3oN13+ztUzneH089dpeDLQX8vIaBEMXklLrGhxr0ZQNhHrBZkFm8Vpbj ymSZyai1orCbj1dqjXPqHXUNlykTTc0R1ecbzfsiMlFfEoXm0/FPF8PR0w363lnt6T5WeMaFYj2j FLtCivZ6DSkuIeRLz0UwfxFtWYR5gu8VjNzz0BoRxXlr+NDM3A/1u9D5+kYfpqdXeMasp+XD3jR5 NeVaJQBh0uawl0Cg8rdbWpE2ux+VrvYecZwKGQXQngcHaWeBIrVwdQfI6RxMYKPh1lHgUEF4t8hJ zRZ/yYkd2x35zAiBFPp64JaIysAhPltDTcKNRvi2K+1UJ6NK
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eqgI2QprNgs70RLb9lnpAYEZ8T8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 29 Oct 2017 12:35:47 -0000

On 10/29/2017 4:14 AM, Eggert, Lars wrote:

> On 2017-10-29, at 11:33, Simon Pietro Romano <spromano@unina.it> wrote:
>> Which is exactly what I’d call adding multipath capabilities to a protocol “by design”, rather than trying to add multipath after the protocol has been specified. I think that security should have taught us a lot, when it comes to distinguishing the "patch it” vs “think of it at design time” approach.
> so we did add multipath to TCP later, and it was painful, but not because we had issues extending TCP's design - it was painful, because the Internet had ossified around a pretty detailed set of assumption about what TCP would look like on the wire.
>
> With, QUIC, if we get the greasing right, that danger is mostly off the table.
>
> Now, we can still mess up the design of QUICv1 so that adding multipath later would be harder than it needed to be, but I'm pretty confident it's enough on our mind that that won't happen.

I would like to see good multipath support in QUIC, but I think we are
right delaying the work. True multipath support would most probably
require a separation between path variables, such as packet sequence
number and acknowledgements, and per connection variables, such as
stream data and control. It will also require serious work on connection
ID and privacy, not to mention a requirement to separate path ID and
connection ID. None of that is impossible, or even very hard, but taken
together it is a set of very disruptive changes for applications. From a
schedule point of view, it seems much more reasonable to wait until V1
is stable.

-- Christian Huitema