Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 10 July 2019 18:01 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1B912038B for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2019 11:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CxiQlBusdfm8 for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2019 11:01:42 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E8B0F120355 for <tsvwg@ietf.org>; Wed, 10 Jul 2019 11:01:41 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6ADF5D921D327A25D0D1; Wed, 10 Jul 2019 19:01:39 +0100 (IST)
Received: from lhreml507-mbb.china.huawei.com ([10.201.109.48]) by lhreml705-cah.china.huawei.com ([10.201.108.46]) with mapi id 14.03.0415.000; Wed, 10 Jul 2019 19:01:30 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: Isabelle Hamchaoui <isabelle.hamchaoui@orange.com>, Alexandre Ferrieux <alexandre.ferrieux@orange.com>, Cociglio Mauro <mauro.cociglio@telecomitalia.it>, Tianran Zhou <zhoutianran@huawei.com>
Thread-Topic: Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
Thread-Index: AdU1z13vAPi6st6TRKOd3SUsz+4ZFQBT3zQQAAfc5OAAAhwakA==
Date: Wed, 10 Jul 2019 18:01:30 +0000
Message-ID: <E92F9C7E59A8854E8BED73140B879B4E01334827@lhreml507-mbb>
References: <6d90788c0d1449699378ea75e2bd7a10@ustx2ex-dag1mb5.msg.corp.akamai.com> <E92F9C7E59A8854E8BED73140B879B4E0133400B@lhreml507-mbb> <7b0dc87ecbcc4d498f966bc55ccdb770@ustx2ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <7b0dc87ecbcc4d498f966bc55ccdb770@ustx2ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.210.169.205]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/EgLH-_KrNd_96k_igxOmDBT9Iv4>
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 18:01:45 -0000

Hi Igor,
Thank you for considering the mention to RFC 8321.
Agree, the combination of Q bit and L bit helps the applicability of the alternate marking method.
In fact, we are also working on another draft in IPPM with the purpose to define how to deploy alternate marking.

Let's discuss further in Montreal.

Regards,

Giuseppe


-----Original Message-----
From: Lubashev, Igor [mailto:ilubashe@akamai.com] 
Sent: Wednesday, July 10, 2019 6:54 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>;; tsvwg@ietf.org
Cc: Isabelle Hamchaoui <isabelle.hamchaoui@orange.com>;; Alexandre Ferrieux <alexandre.ferrieux@orange.com>;; Cociglio Mauro <mauro.cociglio@telecomitalia.it>;
Subject: RE: Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Giuseppe, thank you very much for this feedback and a pointer to RFC 8321.  We'll definitely mention it in the next rev of the draft.

I see that RFC 8321 did introduce what we are calling a "sQuare bit" for alternate marking of blocks of packets. That's a method to estimate upstream loss.

Our draft is also using what we call "Loss event" bit that allows a single observer to estimate the end-to-end loss as well.  The combination of Q bit (RFC 8321) and the new L bit lets an observer do significantly more than RFC 8321 allows. 

- Igor

-----Original Message-----
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; 
Sent: Wednesday, July 10, 2019 10:54 AM

Dear Igor, Alexandre, Isabelle,
I have had a look at the draft and I think it is an interesting proposal for packet loss signaling and it is good to have a protocol independent document.
In addition, I would suggest to add a reference to RFC 8321 that introduces the packet loss measurement methodology through the alternate marking schema, as reported in Section 3 of your draft. 

Best Regards,

Giuseppe


-----Original Message-----
From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Lubashev, Igor
Sent: Monday, July 8, 2019 11:17 PM
To: tsvwg@ietf.org
Cc: Isabelle Hamchaoui <isabelle.hamchaoui@orange.com>;; Alexandre Ferrieux <alexandre.ferrieux@orange.com>;
Subject: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

Alexandre, Isabelle, and I have just posted a draft on a protocol-independent method for endpoints to signal packet loss to the path, while maintaining end user privacy and resisting ossification.  This method can work for any protocol, but the primary focus is, of course, on protocols that encrypt their headers.

We think this loss signaling scheme (just takes 2 bits somewhere that are set by the sender) is an appropriate solution for allowing networks to do their job at providing high QoS and ease of troubleshooting without compromising on encrypted protocol goals.

- Igor

P.S.
  We've implemented this proposal in some Akamai servers and have been using it to serve actual end-user traffic for a subset of Orange customers.  Orange has implemented passive observer that used this signal to detect and identify loss.  We will discuss and analyze the data we collected at maprg (while the signaling protocol details belong to tsvwg).

-----------------------------------------------------------------------------------------------------------------------------------------------

A new version of I-D, draft-ferrieuxhamchaoui-tsvwg-lossbits-00.txt
has been successfully submitted by Igor Lubashev and posted to the IETF repository.

Name:		draft-ferrieuxhamchaoui-tsvwg-lossbits
Revision:	00
Title:		Packet Loss Signaling for Encrypted Protocols
Document date:	2019-07-08
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-ferrieuxhamchaoui-tsvwg-lossbits-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ferrieuxhamchaoui-tsvwg-lossbits/
Htmlized:       https://tools.ietf.org/html/draft-ferrieuxhamchaoui-tsvwg-lossbits-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ferrieuxhamchaoui-tsvwg-lossbits


Abstract:
   This document describes a protocol-independent method that employs
   two bits to allow endpoints to signal packet loss in a way that can
   be used by network devices to measure and locate the source of the
   loss.  The signaling method applies to all protocols with a protocol-
   specific way to identify packet loss.  The method is especially
   valuable when applied to protocols that encrypt transport header and
   do not allow an alternative method for loss detection.