Re: Spin bit as a negotiated option
Kazuho Oku <kazuhooku@gmail.com> Thu, 04 October 2018 09:50 UTC
Return-Path: <kazuhooku@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 B407E130E11 for <quic@ietfa.amsl.com>; Thu, 4 Oct 2018 02:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 EogYQgrHi6Rt for <quic@ietfa.amsl.com>; Thu, 4 Oct 2018 02:50:34 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 E777B130DFB for <quic@ietf.org>; Thu, 4 Oct 2018 02:50:33 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id j4-v6so3992578ljc.12 for <quic@ietf.org>; Thu, 04 Oct 2018 02:50:33 -0700 (PDT)
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:content-transfer-encoding; bh=Zcmf3uVr/PAerLaZFiH8dlGvZ45zEofMwjg+3/RQmMA=; b=YYo5dPEwZR3B3MgtDyOGWqNRVUW5iaKIcP0aGHvA4zJ27T4PHqt7Qv1QWdNDGq2NoC eTYjWcIxzIlMt/tW2nP+Vop+UBXfL4Pai01Ef1qsHIgf2p1ZdULCiYTTy7PxVfxnwrvJ IzIzbxDYQQ1rcAadmgLdYlnzjyL7da7ApSn0qoudgP5n7RN9dyxQIXMBhkYbew8gdF2Z c9n0cmIzGpXfaE12fukZvWaQ8fAvf9s07S70U/A3Pz1ivGTIkkDNX2aQeiyF+2qjByN5 J7H1r8FIQOmKuVvwi4GQ1QBEa9WMmbJFokxyrFq6939x2xPZYCf0EnWUS2eJ/ZRPy1qj PHvA==
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:content-transfer-encoding; bh=Zcmf3uVr/PAerLaZFiH8dlGvZ45zEofMwjg+3/RQmMA=; b=h8DT5XRndQ0w3EP1vnyYKePGJYNZXl5qCsXYvYvLlDCw+mIb31LB9qn8bohij3bOp/ fIspL45knZTadP1S7Eloj+gis1E41H7ppfC8S9dqT5x/TasIjYC9ToMWk7Y5B3Y22Agn VWJf6nem9N3FAuQnCdfwe10O78ukXTLek8UW4v30gQUhQoTNZtGqVF/UScgB4v1EJRqG BzBoYFYNnrl9VEiU4faunnmhjVhxNfJmf1fF/UwHHYU4zGBIfp/steFCTEhcFtbtr1Kd /WdpoRocjkDY2SWaJIycSIFkBcqRkxM7ntGaWfwPhvBvJrGuk8OnPHq849NbrB9MenfT yR/A==
X-Gm-Message-State: ABuFfohd+stzVXH2TFvRpkjNeKd9r4BuJLBcj3DaO+91a16jahJYbOSK d65lyhH03sT3QAr9hK9Qi8s1538S4vVAKMD3aTxLLu1J
X-Google-Smtp-Source: ACcGV61cbJH8yGTgFXuYzZOS6KLPVKUJw0B5r7ZvkNV458NLargoDlalH0EeQ6VwOyOViuMQiKszydSubyU2o1u1S8Y=
X-Received: by 2002:a2e:570b:: with SMTP id l11-v6mr3944881ljb.14.1538646632060; Thu, 04 Oct 2018 02:50:32 -0700 (PDT)
MIME-Version: 1.0
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org> <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> <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>
In-Reply-To: <21082_1538561186_5BB494A2_21082_335_1_26ed0978-a314-37d1-3c97-5924d62ef539@orange.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 04 Oct 2018 18:50:20 +0900
Message-ID: <CANatvzy87Lc-kyzQUcZZS7unvaBQF+DUoEHsd1G0UoPncr4AEQ@mail.gmail.com>
Subject: Re: Spin bit as a negotiated option
To: Lili Peaudchien <alexandre.ferrieux@orange.com>
Cc: IETF QUIC WG <quic@ietf.org>, Brian Trammell <ietf@trammell.ch>, Christian Huitema <huitema@huitema.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cyg3kKgJsfwbgPwD15gFy0lxclg>
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 09:50:37 -0000
Hi, Thank you for starting the discussion specific to how we could possibly negotiate the use of spin bits. Regarding the topic, my preference goes to using the version number field of the long header for negotiating the presence of spin bits, or any additional signal being exposed to the network. For example, QUICv1 without spin bit could use version 0x101, and v1 with spin bit could use 0x102. In the future, we can assign a different version number for QUICv1 with multiple spin + VEC (or people interested in testing the feature can designate a private version number even before that). I see the following benefits to using the version field as a method to negotiate the use of spin bits. 1. One of the concern regarding spin bits has been that they could lead to ossification. Spin bits are not part of the Invariants, but if the observation tools start looking at those bits without checking the version number field, we will have the pressure to not change how the bits are used. Using the version number to indicate the presence of spin bits is the best approach to resolve such concern. 2. We have hoped to roll out multiple versions of QUIC in a small interval so that the version number field does not get ossified. The best solution is obviously to roll out two flavors of the protocol that uses different version numbers at the same time. We will have a real-world use of version negotiation from day one, because we are in a condition where implementors have different opinions on if they should support spin bit :-) The blocker to this approach has been version negotiation requiring an additional round-trip, but that is going to be resolved by #1755. 2018年10月3日(水) 19:06 <alexandre.ferrieux@orange.com>: > > On 10/03/18 09:58, Brian Trammell (IETF) wrote: > > Backing off the MUST for now for such situations is IMO a good tradeoff, > > though, especially since we only need fractions of a percent of deployment to > > start seeing useful signal for baseline/anomaly measurement of large > > aggregates. > > If the consensus is that we must allow for such situations, then there are two > possibilities: > > (a) weak spec language (MAY WISH TO or similar) => many implementations will > simply drop it > > (b) negotiated option where the negotiation mechanism is mandatory > > In the vein of (b), Christian suggested offline to introduce negotiation to > allow for experimentation of the remaining two reserved bits. Then may be we can > synthesize both ideas by the following proposal: > > - in the first few exchanges of the 5-tuple, use the three bits for option > negotiation > > - then use them as defined by the selected option > > Example encodings: > > 000 : nothing > 001 : spin bit alone : S00 > 010 : spin bit + VEC : SVV > ... : other extensions > > The negotiation mechanism allows both endpoints to force 000. > And since it is in the clear first byte, it allows on-path observers to identify > the option without resorting to heuristics; this helps in the case of a small > support ratio. > > > > > _________________________________________________________________________________________________________________________ > > 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. > -- Kazuho Oku
- 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