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

Tom Herbert <tom@herbertland.com> Wed, 10 July 2019 16:28 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 2D46D12027F for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2019 09:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 AGE1ilyfS8VO for <tsvwg@ietfa.amsl.com>; Wed, 10 Jul 2019 09:28:14 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 C5607120199 for <tsvwg@ietf.org>; Wed, 10 Jul 2019 09:27:55 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id k8so2755718edr.11 for <tsvwg@ietf.org>; Wed, 10 Jul 2019 09:27:55 -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; bh=SdVRRmohobw3VR6n4SVLoGOhNlFGnCKbYw9h+bq9Ktc=; b=VSNEymfDDit3xM0XiE05dHdqz+eZVky4w8q1UL4rNv+2U3NSQcJxslyi36hUSNXXBd /6yvbgjQCjcovpLZWmMLFyhLU4TU1rTujjen71CJ/GADSA9FsqCgoqppPYvnCn1e49Kf dTCbwTUv4Acf2qGRI3kiCn+ylQO8ErGAO8jniE8AP91yixQ+HEDx9MbGr05sIVMpAYf6 7LNK7GwTp623zFnUJnKDyk7ojYss0nm1gH1HSNG6qzMOpKcIGPKmBvzYQ1uZOgvJ+24R PtCPIN2V4W2IzcpDeTrVhSLqUWYGOsTUPvHhamK1JRWnYPZPrMsWpRzHh78tiN2GEgGl j0Pw==
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; bh=SdVRRmohobw3VR6n4SVLoGOhNlFGnCKbYw9h+bq9Ktc=; b=KOMVlzktZaL4l9gCAx3/3YeOxhw5BgscC39SF41flQtSfjazaAgnT+1gNg/PMcEL2Z gJbAADnCLDvyMAH53/AsYYHAZ8+6sl6XbKU93nA0Uaw2GSHPKc4tnba0X6otnOzr+znR LdYatJmcJZmwb1AnygtRNDrAvuvzyWJOsPCFTpwSg/NQLrR0JWR05jg9ZWj+NL2HE2as hKP3jCKbMV4DhPTbvP3GMh/6BwzQgD+51d24HsbHNkrSl0R6s6Uzlgu8Xn7cBRg42W6A fmNP11fKC+A1g+DT9qg4KzvHIwgAeSGkV6vQIGkIlAP5rBCG7IUGP2/406BVd+XG6w5h OhGg==
X-Gm-Message-State: APjAAAXxVk07cnYYpn3mhGZy4EvFvmNfmBL0NEHFb8Qln6LxbqpEhHe5 0f3oi4ZX3afjrF5lCmvxyCGobaUj1pBz/QCUrquxkg==
X-Google-Smtp-Source: APXvYqzcycBw5PerY8th76vwH8KffcQvDj/uA9W0hEiDK7UqZSR8kPyI+6w+mGcZtfYXicatnXbWMcGydAraMjuud4E=
X-Received: by 2002:a17:906:229b:: with SMTP id p27mr27449004eja.266.1562776074212; Wed, 10 Jul 2019 09:27:54 -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>
In-Reply-To: <f62eb747-ad70-45e4-bc2f-94eeddf4d693@OPEXCAUBM6F.corporate.adroot.infra.ftgroup>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 10 Jul 2019 09:27:42 -0700
Message-ID: <CALx6S37xz8=PWWf8Pedtx-DTimEfOwWVLjBC5JjXyZ5-XK+Ndw@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, "HAMCHAOUI Isabelle TGI/OLN" <isabelle.hamchaoui@orange.com>, tsvwg <tsvwg@ietf.org>, "FERRIEUX Alexandre TGI/OLN" <alexandre.ferrieux@orange.com>
Content-Type: multipart/alternative; boundary="000000000000c46a23058d562812"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gOsKuK5nxfHCTgjyh3HY-cfIKVs>
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: Wed, 10 Jul 2019 16:28:17 -0000

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