RE: Spin bit decision

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Tue, 02 October 2018 14:48 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 5FFA1130E78 for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 07:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 hzX-h8KgfaSM for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 07:48:14 -0700 (PDT)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79A9128766 for <quic@ietf.org>; Tue, 2 Oct 2018 07:48:13 -0700 (PDT)
Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w92Em5lM017265; Tue, 2 Oct 2018 15:48:05 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0408.000; Tue, 2 Oct 2018 15:48:05 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, Lars Eggert <lars@eggert.org>, "<alexandre.ferrieux@orange.com>" <alexandre.ferrieux@orange.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Spin bit decision
Thread-Topic: Spin bit decision
Thread-Index: AQHUWhYuY5uphqKTlk+gydAimQZJXKULc8WAgAAbJICAACozgIAAHI2AgAAD5ACAAAMhAIAADuGAgAAHNgCAABRogA==
Date: Tue, 02 Oct 2018 14:48:04 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BBAFFA3@bgb01xud1012>
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> <DM5PR2101MB09014906B258D1F96179D085B3E80@DM5PR2101MB0901.namprd21.prod.outlook.com>
In-Reply-To: <DM5PR2101MB09014906B258D1F96179D085B3E80@DM5PR2101MB0901.namprd21.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24054.007
x-tm-as-result: No-12.612500-8.000000-10
x-tmase-matchedrid: 6otD/cJAac27lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p1CannV/b7f2eSt JsQxPDW9wQTqbLJ40jt6pJLn1hitZHrSP9RtGZYoma6DzXaohvOUctRw0zzl2nN4oJrDvdmBzEV DGnc+EfLYK6UiVCRRQY/I8ZCpajgJp4OKIC9Rc5UlqaDT/7H7l7MiWJGbehIJE84BOf/GC8xBpT Dv/pIBigVLdw2DpYln3GYRbGEerQSziThmwPb+1cK1Ib9JAALx+0Sg1I/+5cHMEmMJ+LiV/cINy MXk5L+I6DAgvE9hypaotEtc6aBglLvuuksuYzsCEmjTpXaUdN4PQyhEi9yXBZsoi2XrUn/J8m+h zBStansfRoCwBzgRYj3zSp73HMHc
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--12.612500-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24054.007
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/niHSZoKfmutlkINF1CrOXq20Pns>
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, 02 Oct 2018 14:48:16 -0000

>If we decide to make it a MUST, it seems to me that it would be pretty easy to
>add some logic to check that your peer is 'spinning' the bit. If they are not,
>after a couple of RTTs just to make sure, you could close the connection (add a
>new PEER_NOT_SPINNING error code). If just one or two major
>implementations implement the validation logic, then we could ensure
>interop and compliance for the most part.
>
>- Nick

A hypothetical spin stick.

With a cyncial endpoint operator hat on, I think the realisation spin bit benefits could be minimal. Leading to little incentive to implement spin bit. Using a stick, like causing connection termination, sounds like it will introduce fun and games for interop testing, and deployment on heterogenous real-world networks.

What's the carrot to offer a non-hyperscaler?


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------