Bona fide loss measurement bits

<alexandre.ferrieux@orange.com> Mon, 09 April 2018 21:37 UTC

Return-Path: <alexandre.ferrieux@orange.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 0B82412D965 for <quic@ietfa.amsl.com>; Mon, 9 Apr 2018 14:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.291
X-Spam-Level:
X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 FbPOz1glxQVp for <quic@ietfa.amsl.com>; Mon, 9 Apr 2018 14:37:05 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D37512D960 for <quic@ietf.org>; Mon, 9 Apr 2018 14:37:05 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 71DDA1205A1 for <quic@ietf.org>; Mon, 9 Apr 2018 23:37:03 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 56FF4180076 for <quic@ietf.org>; Mon, 9 Apr 2018 23:37:03 +0200 (CEST)
Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 9 Apr 2018 23:37:03 +0200
Message-ID: <18025_1523309823_5ACBDCFF_18025_318_1_5ACBDD04.2040803@orange.com>
Date: Mon, 09 Apr 2018 23:37:08 +0200
From: alexandre.ferrieux@orange.com
Organization: Orange
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0
MIME-Version: 1.0
To: IETF QUIC WG <quic@ietf.org>
Subject: Bona fide loss measurement bits
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <2DB3AC71-89B1-425C-8128-E673D34B7AFA@trammell.ch> <CA+9kkMD6a_hF-a8J+Tz-kzEVra8dUqsmpgD_PnD+RshhuzjsUA@mail.gmail.com>
In-Reply-To: <CA+9kkMD6a_hF-a8J+Tz-kzEVra8dUqsmpgD_PnD+RshhuzjsUA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.168.234.2]
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/izddOyzy13zVSTl6hOJjxVmK0vQ>
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: Mon, 09 Apr 2018 21:37:07 -0000

On 04/04/2018 20:06, Ted Hardie wrote:
> it seems pretty clear that the passive measurement and diagnostic purposes would
> work with fairly small sequence numbers, maybe even down to sizes small enough
> to make the linkability problem less scary.  The other issues ("does this look
> like quic" and "does this look like a known flow") seem like they don't really
> require packet numbers or even deliberately exposed sequence numbers, just
> consistency.   In other words, if we do anything to expose sequences, the wire
> image we engineer does not have to simply re-use the packet numbers used for
> protocol mechanics. It can focus on the message we want to send to the path instead.

If we're to secure a few bits as a "message we want to send to the path", e.g. 
for loss measurement, please note that subsequence numbers are just one option 
among many, with known shortcomings (only losses between sender and observer; 
lack of robustness to strong loss and reordering).

Instead, building on top of the Spin Bit, we propose a 7-bit extension named 
"Spin Counters":

     http://snaggletooth.akam.ai/IETF-101-HotRFC/10-Ferrieux.pdf

they give both up- and downstream losses, are robust to any level of loss and 
reordering, and leverage the Spin Bit's autoscaling to one congestion window.

_________________________________________________________________________________________________________________________

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.