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