Re: Rechartering QUIC for Post Version 1 Work

Christian Huitema <huitema@huitema.net> Fri, 29 January 2021 17:50 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 F2CC23A11CD for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 09:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 2k5NolQ6MltH for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 09:50:19 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 6B06D3A11CC for <quic@ietf.org>; Fri, 29 Jan 2021 09:50:19 -0800 (PST)
Received: from xse398.mail2web.com ([66.113.197.144] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1l5XuP-000LKq-4C for quic@ietf.org; Fri, 29 Jan 2021 18:50:15 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DS4cJ0c8tzL8P for <quic@ietf.org>; Fri, 29 Jan 2021 09:50:08 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1l5XuJ-0008MY-Ud for quic@ietf.org; Fri, 29 Jan 2021 09:50:07 -0800
Received: (qmail 27273 invoked from network); 29 Jan 2021 17:50:06 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.250]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 29 Jan 2021 17:50:05 -0000
Subject: Re: Rechartering QUIC for Post Version 1 Work
To: Lars Eggert <lars@eggert.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Roberto Peon <fenix=40fb.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
References: <CALGR9oaXpZp87ujmkDAO6Tuy=m-s8qKDY9-azpm_PhVAMfkq9A@mail.gmail.com> <20210126170048.GB364092@okhta> <D01160E4-C89E-4DF5-B0A7-C5138E33D9C1@eggert.org> <20210126170932.GC364092@okhta> <CALGR9oaO8Q7TC9zyajM20gZkZPR1cRDSv-SeDqo0MfaQbgfAjg@mail.gmail.com> <20210126184815.GD364092@okhta> <CAKcm_gNXkCko=H3VofwnubMDctCN7Smx0LDbH-ruYcTk7S4kTg@mail.gmail.com> <CAPDSy+4kVyrvmkd8vDOzASV36Y2iR2HEGzrSkxXJaMmED6JDww@mail.gmail.com> <CAC8QAcc8E3G2r9tzggRgz5t8ZxeqpFu4dwg4bmoLH39DnBHV-Q@mail.gmail.com> <9D6FDFBB-77E1-4AB9-84C2-376690A026DC@eggert.org> <3CDD98E2-92D6-4E5B-838D-CD56BE5BBA1E@fb.com> <CAKKJt-fiH4-Q-jufVimGxutPnfBZ8TbX2xnYTSckmh3Bbmmwrg@mail.gmail.com> <A5E4F422-91C5-4FA2-BA86-7F291172562F@eggert.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <95cf6788-9130-e814-412c-75675c43f19f@huitema.net>
Date: Fri, 29 Jan 2021 09:50:04 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <A5E4F422-91C5-4FA2-BA86-7F291172562F@eggert.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: 66.113.197.144
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCBev 1UoFBfmVxF7Ux9fTBNzmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca9EJlxFy1R8PRglwPYpBBuRQ6V51u76v35b1wNe/MvdIN+Yj9 JT+HIE3AciYbXmyy2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkFDWJmcqHKssKxaylFamaV+b9tZ+C5y Oc2YAGkaEP1NO+wd68fWg8M/DqNJnyxK7mcdCu2mlibEyS19RfuR8H5R17NirEYyqwqMBGrw8ELi qOyD7UxtOMuKFjzK5zsiVohMBqzR52YHar/IFGqdBj1a6IupC5RqLj/k6/wmh+zu68PH12Bh87aa 4YfZs104p87OifVovUq7COge14oi3y0trSOIPpeqwlm2NDGXIJ2x7EtekSh8Zhx/YtERKbWN8E65 bJwwfOCWa1Hfd26B3Yz3u2vx3xkVscjuhlyZByM3r8IeGq4RRh5M7nLD0EqYqp34OeaqZehAskg9 zMpCZ4Qt99CwkyNW5oJ+r5LYXcMk4hEVniihuDwEGDcmr6e3OPQHxzUOEv9x2JozDVWpGqOvfz8h 2tj4aloLqSd3UIr8MXjI60oLXcuhwUdHWP/Eha4NXjcKR5LZIKCLB6H6mfAkwD/3EaCPu1onFa0d n3u5ipIcWpgD1+MrllsO2WsRFClic0YV1E3cK088GNIeQjFlPE48k6wYOikXD7qYhWAa7+c6+0Xs DVtCAGQDUwTZWAv0dxCqGRQPPGR7vmqZQrQOZJ0Q4x+0GOxZvoENDONKwTepoEV8JoWhfuVs2p92 abOQTjYr4mblZJIFx02/rieoYQ012X/617XXv8LOWWL/2TEvuGslKTrRIXcXpFg5ivY=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Yqix7Ildy5D0S7FyFp-lQu_Uwfw>
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, 29 Jan 2021 17:50:21 -0000

On 1/29/2021 12:24 AM, Lars Eggert wrote:
> Hi,
>
> On 2021-1-29, at 2:03, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>> I THINK I'm reading this as the QUIC working group requesting groups that realize that their applications require QUIC extensions to consult with the QUIC working group, and seek review. Is that the intention?
> yes.
>
>> I'd expect that to be stronger, simply because (based on experiences with protocols like SIP) popular protocols tend to collect applications from people who don't understand the underlying protocol as well as the people who are responsible for the underlying protocol. If you can say "but you can accomplish the same thing by using QUIC as it is now", sooner rather than later, that would probably make everyone's lives simpler.
> ...
>> So, maybe that could say something like "are encouraged to consult with the QUIC WG and obtain early review of proposals, thereby avoiding late surprises"?
> I'm proposing a text change based on this suggestion in https://github.com/quicwg/wg-materials/pull/192/files#r566650407


To Spencer's point, I shall observe that the extension mechanisms of 
QUIC are in fact very powerful. Case in point, I just completed an 
implementation of two multipath drafts in Picoquic, both keyed by the 
negotiation of transport options. I also did study the "unreliable 
deliveries" scenario, and it could certainly be deployed through the 
parameter negotiation mechanism. The role of the IETF there is to 
distinguish between experiments and standards.

Pretty much anyone with a keyboard and a github repo can fork one of the 
open source implementations of QUIC and experiment with a new 
functionality. The only downside is that if negotiation fails the 
application has to live with the limitations of QUIC V1, such as single 
path instead of multipath, or reliable delivery instead of immediate 
delivery. To go from there to wide scale deployment, the supporters need 
to convince enough other parties. Hence the need for some kind of standard.

There is an obvious role for the IETF there. In theory, going through 
the standardization crucible will result in better extensions, avoid 
replicating existing work, review security issues, etc. But I am worried 
about time scales. The work on draft-liu-multipath-quic started in 
October, and we see two implementations 4 months later, and we could see 
coordinated deployments within a few more months. Compare that to the 
median time of getting something done in an IETF WG, more than 3 years. 
There are solid chances that by the time the WG concludes the industry 
has already converged on a solution, redundancy with other standards be 
damned.

That's what worries about the charter. How do we match the time scale of 
standardization with the potentially high speed of defining them?

-- Christian Huitema