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

Tom Herbert <tom@herbertland.com> Thu, 11 July 2019 18:07 UTC

Return-Path: <tom@herbertland.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 C854112002E for <tsvwg@ietfa.amsl.com>; Thu, 11 Jul 2019 11:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Level:
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 XyhQT_DBr5BG for <tsvwg@ietfa.amsl.com>; Thu, 11 Jul 2019 11:07:29 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6181200A4 for <tsvwg@ietf.org>; Thu, 11 Jul 2019 11:07:29 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id v15so6698668eds.9 for <tsvwg@ietf.org>; Thu, 11 Jul 2019 11:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Mb1wlW2B9JaGtpl9f5MS81P6PFc+4iyGY/0yydObCAk=; b=lBl2jAcD0gLuf/Wp0Yb3T7aWQ/C1+20tdT22Sju8bpNYIn+gdxocuVp+gHMlNn+CaX CyEqjUyTnR6QTca6V2x+iS5lEBh1PqQ24QPo5yMJ4RoXrYFvHPIadc5EQPW49kvo7nlh +E3NvEVSmct+0Mb+OmWxQGtEZ/z4ebK9q3TFytA5dfexU46GKzFgf4BelSpK076sMrbx TtjU/vVD9IZvhifYkNX6u3QfP5lePCAutK/UH//RhayfAh84UpkWaQNcroaAOcp9vU/9 VPoE4FMBQIN7CeqIUUnfjZwAGlpxXeYAFN3A8HhHTIvAEgbTYq6EKe6orsV8FDyYLWgk Unag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Mb1wlW2B9JaGtpl9f5MS81P6PFc+4iyGY/0yydObCAk=; b=jNcaf/2sp63xvWUfeToNzaX6aUIFltTGnx/FrZldmLQH2fofCf76RunelzthCwv75/ aFxRulpeetucdbJPXY61sh10CmpmwjmIFeo/wjeSjbu5BhlyCFO1U5StJVhENaxpldNY Ng7PawXoqp6v4csUTDn+Gc1KTqoyVwSqlTqugonu4VWi07hMS9dR2qYK4k5UOZbplVJh yvVBo7kYmK2nWuyAYcA/6rqIaZF4Cc69t7tCc+/Yx+6d3eUYg4mYu7c10ObEaUIUOw7s z1BgYQ2xoNZKeaX8AODMK2/pFmd1Fiz7HDpfjX02FKj2dDkfDM6AF8KCoIj82pY5cMMo 5xww==
X-Gm-Message-State: APjAAAXGx1O27u8SyjObl5M2WFNl/7L9iYSFKzQyWBzDg0XGXSBwmQFv paqURHbuVRp/aV95KhnkyHh6ZqgPFF6qSPd7ikk=
X-Google-Smtp-Source: APXvYqxpWxbNB7vOT4B3ya3X4eOXnAX+ot71P81fiQNlXROLturEaJkOsDSWYnQtWmSbZSraYZV4plKJCnFuYfNjcwk=
X-Received: by 2002:a50:b1db:: with SMTP id n27mr5031405edd.62.1562868446811; Thu, 11 Jul 2019 11:07:26 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <08e7ae3e-5ae4-43f2-9758-01480663bb0d@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 11 Jul 2019 11:07:15 -0700
Message-ID: <CALx6S34zJt=ZLRhgm9aL3U1H7YCbr+FwfY+m7USAksfQnpJmLA@mail.gmail.com>
To: mohamed.boucadair@orange.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/E74xe-GXzMZCOM8KwGMxTIDRaqQ>
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: Thu, 11 Jul 2019 18:07:32 -0000

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