IETF Logo Mail Archive

spin bit in QUIC

Roni Even <roni.even@huawei.com> Tue, 14 November 2017 08:42 UTC

Return-Path: <roni.even@huawei.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 8E7BC124D6C for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 00:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 z1-oh0Fj8rqZ for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 00:42:05 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 295581200E5 for <quic@ietf.org>; Tue, 14 Nov 2017 00:42:05 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5B63D9CCE0FCE for <quic@ietf.org>; Tue, 14 Nov 2017 08:42:02 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 08:41:26 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 16:41:07 +0800
From: Roni Even <roni.even@huawei.com>
To: QUIC WG <quic@ietf.org>
Subject: spin bit in QUIC
Thread-Topic: spin bit in QUIC
Thread-Index: AdNdInWu9OoodX6pTBa2nSIjjM2p0w==
Date: Tue, 14 Nov 2017 08:41:06 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.35.96]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836BC1DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/dZZxQ96WrZN2REsWRvt4fJY031I>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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, 14 Nov 2017 08:42:06 -0000

Hi,
It is good that the conclusion about the geo location security issue is that the spin bit does not add privacy risk on top of what can be done without it.

As for the spin bit. RTT calculation are used for trouble shooting in TCP see in draft-even-quic-troubleshooting-video-delivery-00.
The spin bit will provide similar functionality even though it is less reliable as was mentioned since it is not part of the QUIC state machine.
We envision that we will see a lot of QUIC traffic in the network and having the spin bit can help with identifying bottle necks in the network and reducing QUIC latency.  It will be important to have the spin bit in V1 and the main text is already in the github

Thanks
Roni Even

v2.23.0 | Report a Bug | By Email