Re: Spin bit as a negotiated option
<alexandre.ferrieux@orange.com> Thu, 04 October 2018 21:55 UTC
Return-Path: <alexandre.ferrieux@orange.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 C632512D7EA for <quic@ietfa.amsl.com>; Thu, 4 Oct 2018 14:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.291
X-Spam-Level:
X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 zaevOX-NvC6m for <quic@ietfa.amsl.com>; Thu, 4 Oct 2018 14:55:31 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B12130934 for <quic@ietf.org>; Thu, 4 Oct 2018 14:55:31 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 42R6Bn2RQnz5vp0; Thu, 4 Oct 2018 23:55:29 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 42R6Bn1hQNz1xnr; Thu, 4 Oct 2018 23:55:29 +0200 (CEST)
Received: from [10.193.4.89] (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Oct 2018 23:55:28 +0200
Subject: Re: Spin bit as a negotiated option
To: Kazuho Oku <kazuhooku@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>, Brian Trammell <ietf@trammell.ch>, Christian Huitema <huitema@huitema.net>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9737_1538485723_5BB36DDB_9737_147_1_82e0e028-b0e8-5e09-7bd5-e66db97c556a@orange.com> <E7479831-9594-444E-9545-A162E8D9B154@eggert.org> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com> <MWHPR22MB0991D93D706031603B077BFCDAE80@MWHPR22MB0991.namprd22.prod.outlook.com> <CAKcm_gM+zAEwfimHsorsWprJgS7O++85EOjpQoNY0LviaQ+KNQ@mail.gmail.com> <45751C2A-9F6C-4447-8D70-11ABE8C07F8D@trammell.ch> <CANatvzzCvmbu=bN1C-UCzNaT6EUPVCMPwY53wyFNkKa4HQT00g@mail.gmail.com> <E32A1E8D-0FD7-47F3-B026-10D46E201D54@trammell.ch> <21082_1538561186_5BB494A2_21082_335_1_26ed0978-a314-37d1-3c97-5924d62ef539@orange.com> <CANatvzy87Lc-kyzQUcZZS7unvaBQF+DUoEHsd1G0UoPncr4AEQ@mail.gmail.com> <4582_1538649993_5BB5EF89_4582_187_1_98109893-8492-6a58-0534-3fc4eaa09dd9@orange.com> <CANatvzwzw7snBV4bXfhvWJk4znOmv0Er6kwidRR+dPQsfFczkw@mail.gmail.com>
From: alexandre.ferrieux@orange.com
Organization: Orange
Message-ID: <5571_1538690129_5BB68C51_5571_214_1_77c6c0d0-d40c-d44c-e763-bb955eef69ae@orange.com>
Date: Thu, 04 Oct 2018 23:55:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CANatvzwzw7snBV4bXfhvWJk4znOmv0Er6kwidRR+dPQsfFczkw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.168.234.2]
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7MpZ9gql9TfLnMeZaFXVB43kEYc>
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, 04 Oct 2018 21:55:33 -0000
On 10/04/18 23:40, Kazuho Oku wrote: > 2018年10月4日(木) 19:46 <alexandre.ferrieux@orange.com>: >> >> Thanks Kazuho. Using version numbers directly was an obvious choice, but so far >> I was discouraged by strong language in the spec, saying 0x00000001 was the >> unavoidable point of convergence after all 0xFF0000XX experiments. So in essence >> you're proposing to weaken that a bit, right ? > > I am not sure if we have reached consensus that QUICv1 should use > 0x00000001 as the one and only number for the version number field. > > My understanding is that it is simply written as such because I-D is a > draft of a RFC. A RFC needs to clarify the value of version number > field it uses, and I-D needs to have a paragraph that amends on how > the draft-versions uses the field. OK, thanks for the clarification. > I do not think we can segment the version number space, because IMO it > essentially means making spin bits an invariant. My understanding is > that spin bits is something specific to v1. > > QUICv1 might use different values on the version number field to > represent if spin bits is (or other signals are) available, but that > does not mean that v2 will expose the same signals or they would use > the version number field for indicating that. > > If it is the case that the use of 0x1xx for V1 might give people the > impression that the lower bits are used to indicate the availability > of unencrypted signals across multiple versions, I think starting from > 0x00000001 (i.e. the one you describe as "direct enumeration") would > be preferable. Crystal clear, and agreed:) >> Also, are we sure that this explosion won't weigh on the new VN scheme, inducing >> slower convergence due to longer lists on either side ? > > I do not think that is an issue for v1, because what currently at > stake is if we should assign one or two extra version numbers (i.e. > one for spin bit, and possibly another for spin+vec as a separate > draft). > > If folks agree to expose other signals that requires a "configuration" > to be exposed as well, then they can define a new version number that > introduces a new field to the long header format for exposing the > "configuration." OK. So, wrapping up, and abstracting away for now the bit layout of the version number by using symbolic names, we'd start (right after Bangkok) with something like: - "v1" = v1 without extensions - "v1s" = v1 with spin bit only - "v1svv" = v1 with spin bit and VEC - "v1sqr" = v1 with spin bit and loss bits Q and R - etc (?) One question though: what part of the version negotiation exchange is in clear ? IOW, would the selected version always be exposed to the path, or should spin-consumers rely on heuristics to guess the variant in use ? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Marcus Ihlar
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- Re: Spin bit decision Mikkel Fahnøe Jørgensen
- Re: Spin bit decision Brian Trammell (IETF)
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Nick Banks
- Re: Spin bit decision alexandre.ferrieux
- Re: Spin bit decision Brian Trammell (IETF)
- RE: Spin bit decision Lucas Pardue
- Re: Spin bit decision alexandre.ferrieux
- RE: Spin bit decision Lucas Pardue
- Re: Spin bit decision Benjamin Kaduk
- Re: Spin bit decision Lars Eggert
- RE: Spin bit decision Mike Bishop
- Re: Spin bit decision Ted Hardie
- Re: Spin bit decision Ian Swett
- RE: Spin bit decision Mike Bishop
- Re: Spin bit decision Marten Seemann
- signaling that QUIC is QUIC was Re: Spin bit deci… Brian Trammell (IETF)
- a proposed way forward was Re: Spin bit decision Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Marten Seemann
- Re: Spin bit decision alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- Re: Spin bit decision Kazuho Oku
- Re: a proposed way forward was Re: Spin bit decis… alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Mikkel Fahnøe Jørgensen
- Re: a proposed way forward was Re: Spin bit decis… Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Brian Trammell (IETF)
- Re: a proposed way forward was Re: Spin bit decis… Mikkel Fahnøe Jørgensen
- RE: a proposed way forward was Re: Spin bit decis… Lucas Pardue
- Spin bit as a negotiated option alexandre.ferrieux
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- Re: a proposed way forward was Re: Spin bit decis… Kazuho Oku
- RE: Spin bit decision Mike Bishop
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- RE: Spin bit decision Gabriel Montenegro
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- RE: Spin bit as a negotiated option Mike Bishop
- RE: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option Marten Seemann
- Re: Spin bit as a negotiated option alexandre.ferrieux
- RE: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option Kazuho Oku
- Re: Spin bit as a negotiated option Brian Trammell (IETF)
- SV: Spin bit as a negotiated option Marcus Ihlar
- Re: Spin bit as a negotiated option alexandre.ferrieux
- Re: Spin bit as a negotiated option Kazuho Oku