Re: QUIC ossification

Martin Duke <martin.h.duke@gmail.com> Thu, 14 February 2019 04:00 UTC

Return-Path: <martin.h.duke@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 D4B26130F44 for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 20:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uNfIXLipArWk for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 20:00:19 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 230BD1295D8 for <quic@ietf.org>; Wed, 13 Feb 2019 20:00:19 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id y185so3312832wmd.1 for <quic@ietf.org>; Wed, 13 Feb 2019 20:00:19 -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=AgowFZ/+uB0+VEQak54uTSxr4Ns8jdYDfQrG6h0abHk=; b=ILXTiHLRrNAROgiKlpPkK9EeJT4wLSG+JOMXNno5bE4YvWWbFsfC2kXBcvDKRKDMNq ZFjBNmQ/SoYI1dlbWF8fWvrtem2HE6o61x2SUv5einr/xao/QTNU2c5H52Ut9FNfWVsN gOK1Bno/AGwcZvjuTgvOU9JgqGvp77w/4sxpbm3N0jU4HZ9sCl+vAQ7FIIdpPbnP2voM zsLtveIotLzFCn4hDZPHw7YpDQ9Zs+ivZKMltjj0XylPqUqfwfyOj+zJRHFKiTW4xx04 iglMKv3oG1jkjJOkYxLDp+tpPMAilZVUcFZnWXkQ7KSbx1eX4yEkXck5m2GrC5sLVAdX r5KQ==
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=AgowFZ/+uB0+VEQak54uTSxr4Ns8jdYDfQrG6h0abHk=; b=d7GVgKSwsLEwQx0k4zZQ1DbLmt8cUT0oaVn58ocJCL6VPccjINUwm3AB3d7vV9UN0O nAGUZrpEns22oRinpkUXxax5/WuplIABqVOxHCbvXIC1oqLM/kBO8C1dE0ofoagUzRQf kxhpbZvMxUENBq3o1926HVYmUJISw/H1X+9jGoTjqN9sHuZny/ruOxo3XGqdrAAjnnaM uqPYAYdBmbZfnNCkz4+neHHwu1R0hWD9EwDwSm/wnRhe1rIbXSH34lmparAXK5p0xCbO 8q5GdF5bGxKgGd25MP0S6rkEEemU0lRxwsXfNQ00KaSyTu/3iMjQ3b16Z0re+/EPrFD1 TLbw==
X-Gm-Message-State: AHQUAuZ1KbePHtCm0X2Dy+K10jUK5loqCiCt/gFG2JzyNu39skaKVTYv wLTtF5m5VMt15vA15qd6Q6aQkrp1e1gSWxHyo34=
X-Google-Smtp-Source: AHgI3Ibbw/HghxQA/SSSyXl1TPY3kj3qijE5VM2OoztqMuTAz9jlyha5Bhp7l9sZdGxtg8tEcUXV4yU8MQtP4bl/RWk=
X-Received: by 2002:a1c:27c6:: with SMTP id n189mr862601wmn.108.1550116817457; Wed, 13 Feb 2019 20:00:17 -0800 (PST)
MIME-Version: 1.0
References: <CAM4esxTm0GiXnow4Vyv0UX6kFW4U3zJgVrN_JzD31Sm6sxoYGg@mail.gmail.com> <1550007332.441557.1656692832.0E5412AE@webmail.messagingengine.com> <9425344B-D72F-474D-A549-AA2453E57F19@fb.com> <CAPDSy+5LikoojquLhaW58DbJ3VrGXUViaD0aHcTkxBJGzFjgQA@mail.gmail.com> <47E7A834-B6CD-4D73-BF49-8768A48CADF0@fb.com> <CAM4esxThzPJUxU7R5-CY-ZcgmqhYdPFMoM5Fg17vN-Hsk_pJ8A@mail.gmail.com> <CAKcm_gMmxeHHN3dtH9kby_En96oPwTqrfHE=wpqy5Z0YbX4png@mail.gmail.com> <CAN1APdegy8n3+8J-pkgB6f-SNxHtju9p1Hiyct2tHWQ0KyeiGg@mail.gmail.com> <CA+9kkMC95TnFatowKU6121g+1DPy1hMNbKPagveMfKCXtpFSUQ@mail.gmail.com> <5B7F7D53-546D-4E3F-A0FC-AC29B1B05742@huitema.net> <CAKKJt-cQm+D2vptcfCLywz_QmuZW8tMYgcxNLoxyfC67OvYPUw@mail.gmail.com> <271E52ED-FA3A-4B4D-978C-90CE5CE57053@fb.com> <CAKKJt-f4U15Nr316xjuPb2S0QYOO6YAi9HRZzLWaZVfyXT3s8A@mail.gmail.com> <6b503e6a-d9ed-e747-9db6-f943f92fe114@huitema.net> <CACpbDcdixBEBFnLNbN1OhiKv9iTGjCpT3LQH13Rd64x1N0sJsA@mail.gmail.com> <CAM4esxTRsj7WqOSiCKfhQu2CfEosC+1-wJcm9uS1ryjchtpxdA@mail.gmail.com>
In-Reply-To: <CAM4esxTRsj7WqOSiCKfhQu2CfEosC+1-wJcm9uS1ryjchtpxdA@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 13 Feb 2019 20:00:05 -0800
Message-ID: <CAM4esxSqOAHEXXgAYP3iHyb-mkScrkXg1e5Dx+zA=Bi=yAcnQg@mail.gmail.com>
Subject: Re: QUIC ossification
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, Ted Hardie <ted.ietf@gmail.com>, David Benjamin <davidben@google.com>, Martin Thomson <mt@lowentropy.net>, Ian Swett <ianswett=40google.com@dmarc.ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000043d6300581d2b296"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GDAAjwk8_vpTU7fnmDpSFqaHnrU>
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: Thu, 14 Feb 2019 04:00:22 -0000

Would it make sense for "version of the month" to have essentially random
version numbers, rather than have them increase monotonically?

Similarly, setting aside IANA, is it sufficient for big players to accept
ANY version in the short term and treat it as v1, and also have their
clients propose totally random versions?

On Wed, Feb 13, 2019, 7:54 PM Martin Duke <martin.h.duke@gmail.com wrote:

> Just to close the loop on the transport parameter concern: changing the
> salt probably solves the problem. You can't read the TPs unless the
> implementer has processed the new version document.
>
> I like how the version # discussion is progressing, please keep at it.
>
> On Wed, Feb 13, 2019, 6:33 PM Jana Iyengar <jri.ietf@gmail.com wrote:
>
>> I'm with Martin Duke in that even if we trust the IETF process to produce
>> a v2 quicly (sorry), middleboxes could just as simply do "version == 1 or
>> 2".
>>
>> I agree with Christian that we don't need *everyone* to do this; a few
>> heavy hitters ought to be enough to dissuade middleboxes from ossifying a
>> few versions.
>>
>> I'm intrigued by the "version of the month" idea, which is perhaps
>> similar to David Benjamin's idea of running a QUIC version per Chrome
>> cycle. Perhaps big sites (Google, Facebook, anyone else) could periodically
>> publish their new equivalent versions on a wiki, and clients could keep up
>> with them?  Is there a more concrete proposal here?
>>
>>
>>
>> On Wed, Feb 13, 2019 at 6:18 PM Christian Huitema <huitema@huitema.net>
>> wrote:
>>
>>> On 2/13/2019 12:21 PM, Spencer Dawkins at IETF wrote:
>>>
>>> Hi, Roberto,
>>>
>>> On Wed, Feb 13, 2019 at 3:52 PM Roberto Peon <fenix@fb.com> wrote:
>>>
>>>> Better that they have to explicitly block than they accidentally block?
>>>>
>>>
>>> Well, right, but I'm not sure why someone accidentally blocking
>>> (especially QUICv1) is less likely to do that because we created a
>>> registry.
>>>
>>> But I asked Christian a question just before the IAB telechat today, so
>>> I should probably wait to give him a chance to explain what he was
>>> thinking.
>>>
>>>
>>> OK, back to basics. The middle-boxes will only not do something if it
>>> hurts them. Blocking a little guy or blocking some experiment will not hurt
>>> them, because there will be few complaints. Blocking Google or some other
>>> big site, on the other hand, yes that could hurt -- calls to support line,
>>> complaints from ISP who bought the box, etc. So the version will only not
>>> ossify if the big players grease it in a meaningful way, or change it
>>> frequently.
>>>
>>> There are two plausible ways there. One would be a "version of the
>>> month", with at least a change in the clear text encryption key. The other
>>> would be "versions for extensions", tied to for example the negotiation of
>>> new transport parameters. In both cases, having something like an IANA
>>> registry for the version number would help.
>>>
>>> -- Christian Huitema
>>>
>>