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

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 09 July 2019 02:10 UTC

Return-Path: <ilubashe@akamai.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 ED8B812038F for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 19:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 AAuncg9TBluy for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 19:10:54 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 DAAE01203B6 for <tsvwg@ietf.org>; Mon, 8 Jul 2019 19:10:53 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x69271hb007649; Tue, 9 Jul 2019 03:10:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=t1Nkhb/41w2STPCJ/LdoBOdtr6IybVsJh+8s2LOJbkg=; b=i/doMdfeEMjjDC+xTf3yAwKwPDhI4FjLruA87BHfospXO96Dt7WyH4QkjwWKp8IRzD1G K0BlYKAkvbLaMblsqV6QfkiBV4mCF+nPlzQ6WkqcHxXr4k6pXRs7dKV1ucBLHUAWo2/B nUG1viZiui58jsxIcjMCtXwa+YFPfmwkJV8fTp6zxNeK/St12jLvNVGZsTZ+wel63HOu Cj76T0wsmHIOkMK3sUN2yWVh1yYBMTXm88qT/TGchBL7puNdASiNDafjBNjHVkBbMcAn NahX0Wnopi2Reb7m6RQ1KhAVemCWAJSeTqbNYPNnkHSh6HDopqaAk2XXn6gdqlfzJqby VA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2tmd3b8tm1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Jul 2019 03:10:52 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x69229id010723; Mon, 8 Jul 2019 22:10:51 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2tjpyw7e5g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 08 Jul 2019 22:10:51 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Jul 2019 21:10:49 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1473.004; Mon, 8 Jul 2019 21:10:49 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "tom@herbertland.com" <tom@herbertland.com>
CC: "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "isabelle.hamchaoui@orange.com" <isabelle.hamchaoui@orange.com>
Thread-Topic: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
Thread-Index: AdU1z13vAPi6st6TRKOd3SUsz+4ZFQARpQUA///LKRM=
Date: Tue, 9 Jul 2019 02:10:49 +0000
Message-ID: <132b2c1168af4abca668a32db664d2a2@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <6d90788c0d1449699378ea75e2bd7a10@ustx2ex-dag1mb5.msg.corp.akamai.com>, <CALx6S37T2S6ECbjGv9L13BzHauRHb7nA9gDPt8ArwHJGxqPT4w@mail.gmail.com>
In-Reply-To: <CALx6S37T2S6ECbjGv9L13BzHauRHb7nA9gDPt8ArwHJGxqPT4w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_132b2c1168af4abca668a32db664d2a2ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-09_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090024
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-09_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090026
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/92MgwOzL6MqOmTBxFVNi6PP1vRg>
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: Tue, 09 Jul 2019 02:11:06 -0000

Thank you for your comments, Tom. I am pleased that you find intent of the proposal admirable -- this is a major purpose of this draft.

This draft is "informational", not "standards track". Its purpose it to recommend a technique that would be adopted for specific protocols in different protocol-specific drafts, possibly in protocol-specific WGs.

As for our experiment, the bits we used were the two most significant bits of TTL (IPv4) and HopLimit (IPv6). That was done mostly for expediency of the implementation and good interoperability on the network.

Many thanks,

- Igor

-----Original Message-----
From: Tom Herbert [tom@herbertland.com]
Received: Monday, 08 Jul 2019, 8:20PM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: tsvwg@ietf.org [tsvwg@ietf.org]; Isabelle Hamchaoui [isabelle.hamchaoui@orange.com]; Alexandre Ferrieux [alexandre.ferrieux@orange.com]
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits

On Mon, Jul 8, 2019 at 2:20 PM Lubashev, Igor <ilubashe@akamai.com>; wrote:
>
> 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,

While the intent of the proposal is admirable, I think both the draft
and this description gloss over a critical piece of a protocol, namely
what is the exact protocol that the sender uses to convey the
information and the receiver knows how to unambiguously interpret it.
That is, it's not enough to say that it "just takes 2 bits somewhere
that are set by the sender", in order to produce robust and
interoperable implementations we'll need to know _exactly_ where those
two bits live. In passing the draft mentioned "e.g. two most
significant its of the TTL field in IP (see [IP]) and IPv6 (see
[IPv6]) headers or reserved bits in a QUIC v1 header (see
[QUIC-TRANSPORT]).". I'm not sure which of those are intended to be
implemented and standardized (It's not clear to me that any protocol
solution for such signaling, other that IPv6 HBH headers, can be
robustly defined for such signaling).

>
> - 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).

Right, so if you've implemented something already then where were the
bits put in the protocol headers?

Thanks,
Tom

>
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> 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.
>