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

"Lubashev, Igor" <ilubashe@akamai.com> Fri, 19 July 2019 18:14 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 9585912045D for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 11:14:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 1j3nub-MIWmG for <tsvwg@ietfa.amsl.com>; Fri, 19 Jul 2019 11:14:43 -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 3336B12022A for <tsvwg@ietf.org>; Fri, 19 Jul 2019 11:14:43 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x6JIC4d9017070; Fri, 19 Jul 2019 19:14:42 +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 : content-transfer-encoding : mime-version; s=jan2016.eng; bh=LjIr74xx/h5vD1KvHfCjA5Lcru42sPTiMamR8jkFQcY=; b=DCZ2yCWQHbUOo8p18HSj1aAK65MF9z/OX73XkTAw2jS5zg5tQwh8QSbML+zkt+LRjJA6 iu3rp9Iw4Dbjr+wz4kywUhswDB96rDR7ZxBg/ZtaoqpUkIBkSTFuHz7wgv35SIerwdrv ezxlt+i2i9OkVnbmv3v4LIXL3cmD5VR2kqTH25NRP75Mr6wR41FKUZx+J/SAhBO0OFG4 KnREeh3jw23TYaVHGTYYqSBlJ8WpQ0WXHIdGBMvoRELAkPwZz2MXD/7BHR7xe21xhiQU tRF6gEkZOClvqUZOAAax+3B+OPa+NYZJJMjLqxcHZkoQJdQp7dQUinH2u6x/yZUASE3e 2g==
Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2tuen1rxgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2019 19:14:41 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6JI2Ad7026103; Fri, 19 Jul 2019 14:14:40 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2tqan2ckr0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2019 14:14:39 -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; Fri, 19 Jul 2019 13:14:38 -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.005; Fri, 19 Jul 2019 13:14:38 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Tom Herbert <tom@herbertland.com>
CC: HAMCHAOUI Isabelle TGI/OLN <isabelle.hamchaoui@orange.com>, tsvwg <tsvwg@ietf.org>, FERRIEUX Alexandre TGI/OLN <alexandre.ferrieux@orange.com>, RONTEIX JACQUET Flavien TGI/OLN <flavien.ronteixjacquet@orange.com>
Thread-Topic: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
Thread-Index: AdU1z13vAPi6st6TRKOd3SUsz+4ZFQAC+e4AAAPfX4AAAW3TAABS/NfTABoD0oAACx5QYAAEbe6gABaswYAA4bq0gACmLWtA
Date: Fri, 19 Jul 2019 18:14:38 +0000
Message-ID: <000b0c88c6e74719b5d0439443a1e2ba@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <6d90788c0d1449699378ea75e2bd7a10@ustx2ex-dag1mb5.msg.corp.akamai.com> <CALx6S37T2S6ECbjGv9L13BzHauRHb7nA9gDPt8ArwHJGxqPT4w@mail.gmail.com> <132b2c1168af4abca668a32db664d2a2@ustx2ex-dag1mb5.msg.corp.akamai.com> <CALx6S34diayXCMPz-59V9+mpOGzNjqi8x6POfE6Lxgb+9f-qeQ@mail.gmail.com> <f62eb747-ad70-45e4-bc2f-94eeddf4d693@OPEXCAUBM6F.corporate.adroot.infra.ftgroup> <CALx6S37xz8=PWWf8Pedtx-DTimEfOwWVLjBC5JjXyZ5-XK+Ndw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EAC9D66@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <27511937B6D16946B7E6689CD04D231363A33CCF@OPEXCAUBM24.corporate.adroot.infra.ftgroup> <08e7ae3e-5ae4-43f2-9758-01480663bb0d@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CALx6S34zJt=ZLRhgm9aL3U1H7YCbr+FwfY+m7USAksfQnpJmLA@mail.gmail.com> <6057997b-0c44-4203-b872-9b77c49ac5f9@OPEXCAUBM6F.corporate.adroot.infra.ftgroup>
In-Reply-To: <6057997b-0c44-4203-b872-9b77c49ac5f9@OPEXCAUBM6F.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_12:, , 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-1907190193
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-19_12:, , 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-1907190195
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UWVvHsY_1nvFGZtv6tlDa7_QR-Q>
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: Fri, 19 Jul 2019 18:14:46 -0000

Since tsvwg meeting is rather late in the week, I've booked a side meeting on Monday 8:30am-9:30am in Sainte-Catherine for those who are interested to discuss packet loss signaling for encrypted protocols.

- Igor

> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>;
> Sent: Tuesday, July 16, 2019 1:51 AM
> 
> Hi Tom,
> 
> A change is needed for these devices to parse the surplus area. Whether it is
> structured as (1) a fixed header followed by type-specific data or (2) as a set of
> TLVs does not matter much here, IMO.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Tom Herbert [mailto:tom@herbertland.com]
> > Envoyé : jeudi 11 juillet 2019 20:07
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : HAMCHAOUI Isabelle TGI/OLN; Lubashev, Igor; tsvwg; FERRIEUX Alexandre
> > TGI/OLN; RONTEIX JACQUET Flavien TGI/OLN
> > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-
> > ferrieuxhamchaoui-tsvwg-lossbits
> >
> > On Thu, Jul 11, 2019 at 5:22 AM <mohamed.boucadair@orange.com>; wrote:
> > >
> > > Hi Isabelle,
> > >
> > >
> > >
> > > That is not surprising. Some devices are known to drop such packets
> > because of, for example, an assumption of how checksums are computed.
> > There are proposals to fix that (compensate the checksum).
> >
> > Med,
> >
> > Even if we can get middleboxes to pass packets with surplus header,
> > there is still a question of whether any of them would process it like
> > to extract the loss signal information described in this draft. The
> > problem is that network devices are designed to process protocol
> > headers, not protocol trailers. The UDP Extended Header described in
> > draft-herbert-udp-space-hdr-01 might be a way to address that.
> >
> > Tom
> >
> > >
> > >
> > >
> > > IMO, it is too premature to make a conclusion :-)
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : HAMCHAOUI Isabelle TGI/OLN
> > > Envoyé : jeudi 11 juillet 2019 12:19
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Lubashev, Igor; tsvwg; FERRIEUX Alexandre TGI/OLN; Tom Herbert;
> > RONTEIX JACQUET Flavien TGI/OLN
> > > Objet : RE: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > > Hi Med,
> > >
> > >
> > > We’ve tried using UDP trailers to support our loss bits some months ago,
> > and some L4 equipment just drop packets with non-empty UDP trailers.
> > >
> > > So, it seems that using UDP surplus area is not really a viable option
> > either.
> > >
> > >
> > >
> > > Cheers,
> > >
> > >
> > >
> > > Isabelle
> > >
> > >
> > >
> > > De : BOUCADAIR Mohamed TGI/OLN
> > > Envoyé : jeudi 11 juillet 2019 08:53
> > > À : Tom Herbert
> > > Cc : Lubashev, Igor; HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX
> > Alexandre TGI/OLN
> > > Objet : RE: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > > Hi Tom,
> > >
> > >
> > >
> > > Actually, there is no new problem to solve for TCP (and some of the
> > other protocols you mentioned). Existing techniques are OK, see for
> > example the discussion in https://tools.ietf.org/html/rfc8517#section-2.1.
> > >
> > >
> > >
> > > Supplying these bits at the network layer would be ideal, but as you
> > know there is no such common layer. IPv6 extensions will be obviously
> > specific to IPv6 and similar extensions to IPv4 would be needed… which is
> > more challenging given that no viable option is left in that space.
> > >
> > >
> > >
> > > The UDP surplus area solves that problem for both IPv4 and IPv6.
> > Obviously, it applies when UDP is used as underlying transport which
> > covers the QUIC case and many encap protocols relying upon UDP for NAT
> > traversal, entropy, etc. matters.
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : Tom Herbert [mailto:tom@herbertland.com]
> > > Envoyé : mercredi 10 juillet 2019 18:28
> > > À : BOUCADAIR Mohamed TGI/OLN
> > > Cc : Lubashev, Igor; HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX
> > Alexandre TGI/OLN
> > > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Jul 9, 2019, 1:44 AM <mohamed.boucadair@orange.com>; wrote:
> > >
> > > Hi Tom,
> > >
> > >
> > >
> > > I do think there is a value in structuring this as a 2-stage effort:
> > >
> > >
> > >
> > > (1)This draft, as it currently stands, which sketches the overall
> > framework. I do see a value in having this generic framework document
> > without going into details about which signal channel is used.
> > >
> > > (2)Applicability document(s)(?) which will focus more on how to convey
> > these bits: HBH is an option for IPv6, but I suggest to explore the
> > “surplus area” (udp-options) as this may be valid for both v4/v6.
> > >
> > > Med,
> > >
> > >
> > >
> > > The UDP surplus area is only useful for UDP. It doesn't help TCP for
> > instance (or SCTP, DCCP, IPsec, etc.). This is why information belongs in
> > the common network layer; we don't have to worry about how to support
> > network visible information in each and every possible transport protocol.
> > >
> > >
> > >
> > > Tom
> > >
> > >
> > >
> > > Cheers,
> > >
> > > Med
> > >
> > >
> > >
> > > De : tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Tom Herbert
> > > Envoyé : mardi 9 juillet 2019 04:52
> > > À : Lubashev, Igor
> > > Cc : HAMCHAOUI Isabelle TGI/OLN; tsvwg; FERRIEUX Alexandre TGI/OLN
> > > Objet : Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols:
> > draft-ferrieuxhamchaoui-tsvwg-lossbits
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 8, 2019, 7:10 PM Lubashev, Igor <ilubashe@akamai.com>; wrote:
> > >
> > > 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.
> > >
> > >
> > >
> > > Igor,
> > >
> > >
> > >
> > > On one hand, it's good that the signaling is being done in the network
> > layer protocol, that justifies the argument that the mechanism is
> > transport independent or at least transport agnostic. On the other hand,
> > commandeering bits in protocol headers that are already allocated is
> > obviously something that shouldn't be standardized (we've previously seen
> > other attempts to repurpose defined IP fields; stealing bits from the IPv6
> > flow label seems like a common idea!).
> > >
> > >
> > >
> > > For a longer term solution, the alternative is to use the extensibility
> > mechanisms of IP (options in "legacy" IPv4, extension headers in IPv6).
> > For instance, it would be interesting to define a Hop-by-Hop extension
> > header for the loss signaling. One caveat is that a single HBH option
> > gives at least 32 bits of data to work with, so it makes sense to pack as
> > much functionality into an the option (e.g I'm thinking maybe latency
> > signaling, which also can done in two bits, might be another function in
> > the grand "Transport metrics" option).
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Tom
> > >
> > >
> > >
> > >
> > > 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.
> > > >