Re: QUIC ossification
Jana Iyengar <jri.ietf@gmail.com> Tue, 19 February 2019 03:36 UTC
Return-Path: <jri.ietf@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 CFB91130E64 for <quic@ietfa.amsl.com>; Mon, 18 Feb 2019 19:36:09 -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=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 0IpLq3xNGLnK for <quic@ietfa.amsl.com>; Mon, 18 Feb 2019 19:36:07 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 8C5B0130E5F for <quic@ietf.org>; Mon, 18 Feb 2019 19:36:06 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id w6so11368195ljd.7 for <quic@ietf.org>; Mon, 18 Feb 2019 19:36:06 -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=hVJI8RKNw9tIixB/9huAgk5SrFMyPATU7qASthjLVO0=; b=YwL6BQYsZk0z/+zSV2KeHAK1rXSw0RCTsFawdQys4foWVtW3d3C41MxgKu5O2SK0a3 vYIw3hpDDKgYuTiKOnE8yj0nEzG8zfWWTTYUc2v+S9PY+SC14ei8wViLts8977ZBP1UI XCToDpMB9YuRLwHv6WrmQq6jVWAySYCt+xENhxhDcvETCZpTPhSOoJ/eSo/Z6vGdLVmE ynAp8hzhGZRrsxoSDSTWFklsJsXUJQRq0zcLma2jOh4oDXyZdEU/mTX/x9kVr3SAijMK E/Xhm9zfGxDtSG8perExVSlrxqpaXaTiv+AclBa3vr0Wn0wURpq61ShEWM76cX6dbs6s G9eA==
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=hVJI8RKNw9tIixB/9huAgk5SrFMyPATU7qASthjLVO0=; b=GyIJbw+/h9xy6J3c1pKTVooHRiQqpvhbWA+fnY2z4A4o2AH7+DKMArXBxWPwmSgd8U hsrqHYIFux3EBJxzFW8Yc3JbSSVWSg8TJn2K7e8+fwEHXO1NPnvHcFwQORoOXoi81NTD D2G8DXKTAvA8ouCSIYaSJz9L5Nb/f6o8oqbvvlzfrQbNqbooFVz8iXG2La3vdDl3ilKm 0l39cX1cpn/ZhKkiz0jmG7BK5tyY99sb0LFQrgl7R5l0DruwwjjnUovh6YzV+CBOYDEo a+evmPpkC6Yo08rOVcxE/9ENEwIYFgAoI4BOSGJr5qWW6R31xI+FQ5tDao8zSYEIx/Cu /RMg==
X-Gm-Message-State: AHQUAuZNdNaQI3Jr/VMrPxzIRMf6YRlEzDQBZv5Mihzr0QeuGywE3MOs 19WCmbq6fXe72r2u3tZ8SIku08GxsxXZkJMIV7w=
X-Google-Smtp-Source: AHgI3IYAa5657sUcaswtxignNgMMCLgeyDAEVRaeBYW/lnIKZjOMCYcAsfWk4+D+LM9BK8kJj2V3SUZnNXJKwA/rhUA=
X-Received: by 2002:a2e:2285:: with SMTP id i127mr7344961lji.40.1550547364657; Mon, 18 Feb 2019 19:36:04 -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> <CAM4esxSqOAHEXXgAYP3iHyb-mkScrkXg1e5Dx+zA=Bi=yAcnQg@mail.gmail.com> <1550117350.927768.1657684024.116377B8@webmail.messagingengine.com> <CACpbDceGpp2Vs1pztJB3o7CJqg2f4HbL2mOoJtEPPeL7CvbXsA@mail.gmail.com> <1550120918.954942.1657706568.2C59A22F@webmail.messagingengine.com> <DB6PR10MB1766CDECAEED8E8391F61CD4AC670@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CAF8qwaD8TKN251Ru5Q0G+NH9osyVw8MqWY5g+7VvLkzQph6jOQ@mail.gmail.com> <MWHPR22MB09916CC98D4AB60AA6A185BEDA670@MWHPR22MB0991.namprd22.prod.outlook.com> <CAPDSy+4=+Kpx0AD-xOuGJJec2T-MoFX9GOgfKWFPOPkj8D1MBg@mail.gmail.com> <CAM4esxSem6kkcd3rE7qfHJD9A1urmssoVsnagEmtJn7MU=mo5g@mail.gmail.com> <65405c4c-9bf7-4dca-91a3-d4a650ecfeb0@www.fastmail.com> <CAPDSy+4=HzVzm2zVpyt+Fuf4NQq_qyZXy6Ga==rBMnebsSyPpA@mail.gmail.com> <1c10b7bb-380a-4ac8-a3f8-fe185efa9b6b@www.fastmail.com> <CAKcm_gM1BdWAw6xHgWTGWwpThwtDwrkZBZU19VmCR4TXMFMPxA@mail.gmail.com> <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com>
In-Reply-To: <41c7ef89-88e0-41bd-a62f-eb3828a09568@www.fastmail.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Mon, 18 Feb 2019 19:35:53 -0800
Message-ID: <CACpbDceKcBFCde_5ddC+Rbj6SrK7u_L3eAWdJ6XcHpjgzYE6vw@mail.gmail.com>
Subject: Re: QUIC ossification
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0bd58058236f084"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f0iflTMPI2DDltX1JMM5a7VwKKY>
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: Tue, 19 Feb 2019 03:36:10 -0000
On Thu, Feb 14, 2019 at 6:43 PM Martin Thomson <mt@lowentropy.net> wrote: > On Fri, Feb 15, 2019, at 12:22, Ian Swett wrote: > > I believe the concern is that a middlebox/etc will conclude that a > > certain range of versions are IETF standard versions and should be > > allowed and others are fine to block because they're experimental, > > thereby making the majority of versions largely undeployable. > > That only suggests to me that we not segregate the space. The proposed > variations won't all happen in that space. > The whole point of the proposal was to avoid segregating this space. Let me articulate a bit better, and folks can poke holes. Whatever we choose for the on-wire representation of version 1, that's visible to mboxes and they can ossify around it. We want more versions on the wire to avoid this from happening. As long as a few major players use a few more versions on the wire besides v1, that's all we need to keep the ecosystem from ossifying. Ideally, the additional versions keep changing over time to avoid those getting ossified as well. So a server can simply choose a random version periodically and use it. But we need clients to use the version as well, and since not everyone is Google, we use IANA to publish this new version. Basically, (i) org requests new version from IANA, (ii) IANA either assigns a new version (randomly) or approves the requested version for use as additional v1, and (iii) clients and servers roll out support for this new version. Note again that all servers and clients continue supporting the original v1 version; this is an additional preferred version when it is available on both sides. This gets us greasing, and ensures that we have a mechanism in play that protects against downgrade protection. Let's say we use 0x00000001 as v1. Do we allow 0x00000002 as an additional version for v1? If we do, then what is the on-wire representation for v2? If we don't, then we have to segregate the space. To avoid this problem, I suggested that we randomize everything. It's not that hard: IANA can easily assign a version to us at RFC publication time much in the same way as they would to anyone requesting an additional on-wire version for v1 in the future.
- QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Ian Swett
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification David Benjamin
- RE: QUIC ossification Mike Bishop
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification David Schinazi
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Ian Swett
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Spencer Dawkins at IETF
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Ted Hardie
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Brian Trammell (IETF)
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Erik Kline
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Christian Huitema
- Re: QUIC ossification Mikkel Fahnøe Jørgensen
- Re: QUIC ossification Martin Thomson
- Re: QUIC ossification Jana Iyengar
- Re: QUIC ossification Kazuho Oku
- Re: QUIC ossification Roberto Peon
- Re: QUIC ossification Martin Duke
- Re: QUIC ossification Mirja Kühlewind
- RE: QUIC ossification Mike Bishop
- Re: QUIC ossification Martin Duke