RE: spin bit in QUIC: troubleshooting

Roni Even <roni.even@huawei.com> Tue, 14 November 2017 15:26 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 9CD67124D37 for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 07:26:44 -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 YVaQpQUL3nl2 for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 07:26:43 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF587126C89 for <quic@ietf.org>; Tue, 14 Nov 2017 07:26:42 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5A684B4271594 for <quic@ietf.org>; Tue, 14 Nov 2017 15:26:39 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 15:26:40 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 23:26:35 +0800
From: Roni Even <roni.even@huawei.com>
To: Ian Swett <ianswett@google.com>, "emile.stephan@orange.com" <emile.stephan@orange.com>
CC: QUIC WG <quic@ietf.org>
Subject: RE: spin bit in QUIC: troubleshooting
Thread-Topic: spin bit in QUIC: troubleshooting
Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdF///x3sA//9w/SA=
Date: Tue, 14 Nov 2017 15:26:35 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com>
References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <CAKcm_gPRtyzL+jAd6kBSHvDaCYQtbFwXMVVph1SWezVzmNuU_A@mail.gmail.com>
In-Reply-To: <CAKcm_gPRtyzL+jAd6kBSHvDaCYQtbFwXMVVph1SWezVzmNuU_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.42.211]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836D79DGGEMM506MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eO6micW9bNxpR_qhaZeKAOlEgvc>
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 15:26:44 -0000

I think that latency is what we need right now.
Once we understand more about quic and packet loss (will ECN be used reducing packet loss) and other functionality we can see what else is needed. This may be done in next version using variants.
Roni

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: יום ג 14 נובמבר 2017 16:51
To: emile.stephan@orange.com
Cc: QUIC WG
Subject: Re: spin bit in QUIC: troubleshooting

What would the other bit or two be used for?  If there is no standardized use of those bits in v1, then I believe we should wait to reserve them when their usage is defined, given we'd need a version bump to specify how they were being used.  At the moment, the management use case is not competing with anyone else for bits in the short header.

On Tue, Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com<mailto:emile.stephan@orange.com>> wrote:
Hi

Last week Orange experienced a fallback of QUIC to TCP on one of its networks. The issues were not visible in QUIC traffic. The troubleshooting was made using TCP packets information. This is not sustainable on the long term when numerous applications using different versions of QUIC will stop to fallback to TCP.

Based on the exchange we had in the RTT design team and in today meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 bits as discussed in the design team) for manageability in the QUIC invariants and to start experimenting the spin bit in QUIC V1.

Regards
Emile


_________________________________________________________________________________________________________________________



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.