RE: spin bit in QUIC: troubleshooting

"MORTON, ALFRED C (AL)" <acmorton@att.com> Wed, 15 November 2017 02:55 UTC

Return-Path: <acmorton@att.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 254891294B7 for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 18:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 QPtGMWSk60fV for <quic@ietfa.amsl.com>; Tue, 14 Nov 2017 18:55:41 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9BA1294C4 for <quic@ietf.org>; Tue, 14 Nov 2017 18:55:35 -0800 (PST)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF1js9n025090; Tue, 14 Nov 2017 20:52:22 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2e88vjcbgw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 20:52:22 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1qKWf031511; Tue, 14 Nov 2017 19:52:21 -0600
Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1qGBs031502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Nov 2017 19:52:16 -0600
Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Wed, 15 Nov 2017 01:52:00 GMT
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1q0xm007816; Tue, 14 Nov 2017 19:52:00 -0600
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1ptfm007559; Tue, 14 Nov 2017 19:51:55 -0600
Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id C6FF0F0EEC; Tue, 14 Nov 2017 20:51:54 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 20:51:54 -0500
From: "MORTON, ALFRED C (AL)" <acmorton@att.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+idYSdWDiJw89tZdFwAULTIAAAbTAwAABsr3AAABszfg
Date: Wed, 15 Nov 2017 01:51:54 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com>
References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <CAKcm_gPRtyzL+jAd6kBSHvDaCYQtbFwXMVVph1SWezVzmNuU_A@mail.gmail.com> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <CAKcm_gOBh5k1aYm7UT=n-XXH2=7N53VUYwhZSrx5z-OBaMJ9sQ@mail.gmail.com>
In-Reply-To: <CAKcm_gOBh5k1aYm7UT=n-XXH2=7N53VUYwhZSrx5z-OBaMJ9sQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.131.38]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF490457FAnjmtexg5researc_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150023
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rHHdCfQZZ0s5ULox37rWIh4SGho>
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 02:55:43 -0000

I’d like to offer support for Spin Bit (and one or two
bits for management if they can be justified quickly) in v1.
On this topic of more bits,
asking further clarification from Emile, below [ACM].
Al

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Tuesday, November 14, 2017 4:21 PM
To: emile.stephan@orange.com
Cc: QUIC WG
Subject: Re: spin bit in QUIC: troubleshooting

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.
[ACM]  There may be some overlap with ECN and « one bit for congestion ».
Did you also consider this dependency, Emile ? (I’m echoing a hallway discussion)

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.