Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
<mohamed.boucadair@orange.com> Tue, 16 July 2019 05:50 UTC
Return-Path: <mohamed.boucadair@orange.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 9A45B120046 for <tsvwg@ietfa.amsl.com>; Mon, 15 Jul 2019 22:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TIZgE2c0RYNF for <tsvwg@ietfa.amsl.com>; Mon, 15 Jul 2019 22:50:41 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46895120020 for <tsvwg@ietf.org>; Mon, 15 Jul 2019 22:50:41 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45nqHz3sfSz21GP; Tue, 16 Jul 2019 07:50:39 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45nqHz2M83zDq7m; Tue, 16 Jul 2019 07:50:39 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 07:50:36 +0200
From: mohamed.boucadair@orange.com
To: Tom Herbert <tom@herbertland.com>
CC: HAMCHAOUI Isabelle TGI/OLN <isabelle.hamchaoui@orange.com>, "Lubashev, Igor" <ilubashe@akamai.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: AQHVOBOAXDKD1A8SEEmx7Asoru1NfabMw4Ww
Date: Tue, 16 Jul 2019 05:50:35 +0000
Message-ID: <6057997b-0c44-4203-b872-9b77c49ac5f9@OPEXCAUBM6F.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <CALx6S34zJt=ZLRhgm9aL3U1H7YCbr+FwfY+m7USAksfQnpJmLA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/01ofWLORASDUR2caWRaU4odIFLI>
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, 16 Jul 2019 05:50:45 -0000
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. > > >
- [tsvwg] Packet Loss Signaling for Encrypted Proto… Lubashev, Igor
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Tom Herbert
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Lubashev, Igor
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Tom Herbert
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… mohamed.boucadair
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Giuseppe Fioccola
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Tom Herbert
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Lubashev, Igor
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Giuseppe Fioccola
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… mohamed.boucadair
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… isabelle.hamchaoui
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… mohamed.boucadair
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Tom Herbert
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… mohamed.boucadair
- Re: [tsvwg] Packet Loss Signaling for Encrypted P… Lubashev, Igor