Re: R: spin bit in QUIC: troubleshooting

Liang GENG <liang.geng@hotmail.com> Wed, 15 November 2017 08:15 UTC

Return-Path: <liang.geng@hotmail.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 9D4F1129484 for <quic@ietfa.amsl.com>; Wed, 15 Nov 2017 00:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level:
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 tLzrfKZltzEr for <quic@ietfa.amsl.com>; Wed, 15 Nov 2017 00:15:39 -0800 (PST)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253108.outbound.protection.outlook.com [40.92.253.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68338129549 for <quic@ietf.org>; Wed, 15 Nov 2017 00:15:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JCsglcyw+RNLDBT+Dw1PGyyrxknndcxY3wWJqS6UmHQ=; b=f3IXDkJNualKhycRFEJR85zbCpYKWUqeKcv4A5+Mn7bw11oZGXCMmI/RQBxrbg+uUGLnTHUThzeXy+TTiWMfIaOegPLlUrYSvQqbsO08L2aR2KgL2QTVFxQPxx7qYvWKqrVKrLBlA38gPa3t68CRDiZqa/3NSWCLvEiQ8sZvs9W+bmk/rJT6syCVSP06+oHG4F4YfiXx0YmneAu3PcMNiNArkjAKDa8mgkG8Iv/yGONdQbVR8bs2LvY08EQPC4POWq2WPeyfVkYPoZXfd6oakx0KY0DpZAvQaFIAd+C5RgTVuyEhlJ+45fLzw50hs9uYsVAtgxXiiOm4XZlHsrgVug==
Received: from HK2APC01FT048.eop-APC01.prod.protection.outlook.com (10.152.248.60) by HK2APC01HT115.eop-APC01.prod.protection.outlook.com (10.152.249.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4; Wed, 15 Nov 2017 08:15:35 +0000
Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com (10.152.248.60) by HK2APC01FT048.mail.protection.outlook.com (10.152.249.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5 via Frontend Transport; Wed, 15 Nov 2017 08:15:34 +0000
Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::4176:7396:9664:9b40]) by PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::4176:7396:9664:9b40%14]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 08:15:34 +0000
From: Liang GENG <liang.geng@hotmail.com>
To: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>, "Huangyihong (Rachel)" <rachel.huang@huawei.com>, "DRUTA, DAN" <dd5826@att.com>, Ian Swett <ianswett@google.com>, quic <quic@ietf.org>
CC: "emile.stephan@orange.com" <emile.stephan@orange.com>
Subject: Re: R: spin bit in QUIC: troubleshooting
Thread-Topic: R: spin bit in QUIC: troubleshooting
Thread-Index: AdNdsWjQiXFl+idYSdWDiJw89tZdFw==
Date: Wed, 15 Nov 2017 08:15:34 +0000
Message-ID: <PS1PR0601MB1483F8B2EB22D710B676919887290@PS1PR0601MB1483.apcprd06.prod.outlook.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com>, <6d41835fd0a448e583a8f845ec5f5508@TELMBXB02RM001.telecomitalia.local>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: telecomitalia.it; dkim=none (message not signed) header.d=none;telecomitalia.it; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:13772AE53670D965C195AF6548F09EB0D60680BB559EE5CDECF5DC8F5BA197BB; UpperCasedChecksum:AF405B25B0C870FA561C7D785000BBFC4901064397886B0DCB38CA9F5A4BABA1; SizeAsReceived:7311; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [IEKLENgE3qktopWTSCRIBOCPvYNZH3+Q]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT115; 6:40Lr7EkPvl6rUsDzv1xA/nIikeO6Ev9U3OOwon6ZuJLkFA90s8B085bfv0q5nNGpqVTKCbKlrWh3+rYyUk69R65YTdq0lJQI+kcxyGi/vt/y4YvN7biuguUJwzUlqCGN0IZ+2NXUESK4pNYhNVU/0tFfWxPbPFH6085eNkxbVxbyP5nAkvqGo9+ESl1MrWSWG1HEaIckE3h+GFZpiC9D5CXFZD3sx3eLhpZYp8U7hgFa6fwFO8e+PaEONjz4SJEakMZktC3N/pi9MlhbIMpLXgHToN2MCfhfrqCWI/l5ToQDJFlJOz06hqNluv73lpjdn5/0m8AFLV0USW5GmmGnhQ==; 5:9LHUNQvtfiqf2+JNyXzpDhELhg6/5wkzZ5Gzmm7Q47VOltYkta9iIeFz9UzZN4uiOaTYB6ahSwNhijECjIC82lnkYRKLP6YAlXWdMp6t9sB025blj9iS7HbcSvrDpPKavviaCKF4WEOhWRYK1Aw3aA==; 24:k60cvAWWw5l775PoUsxEAJKivlihiSLDnDNOWH8THTn8V0dl7VJR/yGlLkBhRx9qkM/YSY7jO7KxHTi4VWJBxaUg5wTh/ql5op99tIAWxRc=; 7:EZ8YvmMmj4Py8E9oJuHKChQNPHOp2S47hPQyVgZm+1vtWmmYsOcojH2P1cms/ThwhQwlfUKF9oRjM5H0Pi5PFrEo9cBnkv/mm+4L2gOAaHhgcH0NtKNNpwXJ7zIn5OlpTybpQnVLYz/N35eGomeddNh3lfC7XrXHeglkGcrZ+wjnBNRanyM50JDtFeeJofueBqE7gEGyxKMpJJbEhUWYQGyMDtBoPLlK2Hx4EuU4Kag=
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 63e06010-0936-45bd-1bec-08d52c010af2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT115;
x-ms-traffictypediagnostic: HK2APC01HT115:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HK2APC01HT115; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2APC01HT115;
x-forefront-prvs: 0492FD61DD
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT115; H:PS1PR0601MB1483.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_PS1PR0601MB1483F8B2EB22D710B676919887290PS1PR0601MB1483_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 63e06010-0936-45bd-1bec-08d52c010af2
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 08:15:34.4897 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT115
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/45L8_Y_ZOo8vMGiHFd_1gO5qE3k>
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: Wed, 15 Nov 2017 08:15:41 -0000

Hi all,

I also support the inclusion of the spin bit. As network is going to be equipped with more diversified dedication (much finer granularity , i.e. slicing), monitoring and measurement will be even more essential for maintain various type of guarantees (latency, bandwidth, deterministic etc.). Spin bit is a not-to-miss feature for Quic itself to fit in this near-future evolution.

Best wishes
Liang


________________________________
Liang GENG
China Mobile Research Institute

From: Fioccola Giuseppe<mailto:giuseppe.fioccola@telecomitalia.it>
Date: 2017-11-15 10:54
To: Huangyihong (Rachel)<mailto:rachel.huang@huawei.com>; DRUTA, DAN<mailto:dd5826@att.com>; Ian Swett<mailto:ianswett@google.com>; QUIC WG<mailto:quic@ietf.org>
CC: emile.stephan@orange.com<mailto:emile.stephan@orange.com>
Subject: R: spin bit in QUIC: troubleshooting
Hi All,
I support the inclusion of the spin bit into V1. My suggestion is to have one bit for packet loss, one for latency and one for congestion. I would also mention draft-ietf-ippm-alt-mark that details how to use one bit or two bits for packet loss and latency calculation.

Best Regards,

Giuseppe

Da: QUIC [mailto:quic-bounces@ietf.org] Per conto di Huangyihong (Rachel)
Inviato: mercoledì 15 novembre 2017 02:35
A: DRUTA, DAN; Ian Swett
Cc: QUIC WG; emile.stephan@orange.com
Oggetto: Re: spin bit in QUIC: troubleshooting

That’s a good point. I really think the balance should be achieved between privacy and operation. Spin bit is a good example. I support it.

BR,
Rachel

发件人: QUIC [mailto:quic-bounces@ietf.org] 代表 DRUTA, DAN
发送时间: 2017年11月15日 9:11
收件人: Ian Swett <ianswett@google.com<mailto:ianswett@google.com>>
抄送: QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>; emile.stephan@orange.com<mailto:emile.stephan@orange.com>
主题: Re: spin bit in QUIC: troubleshooting

I will add my support for the inclusion of the spin bit into V1 and make a few more points.
Considering that the design team analysis concluded that the spin bit does not add any additional privacy risk and the very specific need addressing latency has been documented and validated by a large number of WG members, I believe the QUIC working group has a unique opportunity to show that we can design protocols that are efficient, privacy sensitive and network management friendly.
This particular design, while not perfect does have the biggest benefit relative to the risks and it should be adopted from the beginning.
Best Regards,
Dan


On Nov 15, 2017, at 5:21 AM, Ian Swett <ianswett@google.com<mailto:ianswett@google.com>> wrote:
Thanks for clarifying Emile.

On Tue, Nov 14, 2017 at 1:06 PM, <emile.stephan@orange.com<mailto:emile.stephan@orange.com>> wrote:
Hi Ian,

It was suggested in the latest discussion on the RTT design team mailing list to have one bit for packet lost, one for latency (spin bit or eq.) and one for congestion.
It seems a simplistic approach on one hand but an invariant on the long term.

Regards
Emile


De : Ian Swett [mailto:ianswett@google.com<mailto:ianswett@google.com>]
Envoyé : mardi 14 novembre 2017 22:51
À : STEPHAN Emile IMT/OLN
Cc : QUIC WG
Objet : 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.


_________________________________________________________________________________________________________________________



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.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.