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

Tom Herbert <tom@herbertland.com> Tue, 09 July 2019 02:52 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 334C71200B7 for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 19:52:00 -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 rCez1xkwTIM6 for <tsvwg@ietfa.amsl.com>; Mon, 8 Jul 2019 19:51:58 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 F357E12008B for <tsvwg@ietf.org>; Mon, 8 Jul 2019 19:51:57 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id e3so16267923edr.10 for <tsvwg@ietf.org>; Mon, 08 Jul 2019 19:51:57 -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=N9OAIOJesV64ltnNzKFRAUPeXRbiDQTR/jIrI6vtJ7g=; b=QulNn8aaXVaZ5Yek5iKNYuMHvtqs8UvWapKWJ0moFkOrIqdkZsPt7XzcOzjLZwATX8 83Z20de/6MltNRm3GgaEy+6VcWMilIuabtm02/AHF0eGLj/C6Uf7xKLF/78sQpvVCHQP 3rQImAwaDBWE0LnmRRdMNerHsws9PQVxFU5P5yE2044XBjo9Q8G0MRP2KynZxZHo4rd7 dAfn8AMFI4fp21SSy06Idh4vDCACZfNOaz6wKxYafOnPpER+V+Fhn3eocTyG7dSg5llm kWSkbzdZAjt7gRwVtWilO4FYDhnI7UmK341Y1SEiFCXfkRf6vFuOOqpa8H4AJ5XsVRNb eYJA==
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=N9OAIOJesV64ltnNzKFRAUPeXRbiDQTR/jIrI6vtJ7g=; b=Ihu70ZlO2e1wnLT4dxmE8Pffsi+fnQ24Wp+gGbgceQGqbTFpmGB3YAzpdFPvncxpPx 58rKVAEUNIS+ZDhotjSGwhlhQJT23/ZarVdFT3cZTovkDHtQb4MSO/gFZ/nBNG6K0VHW 89YpNxL483d3vWD9czQ8dI5/Xhzf/u25aUibBEMJjNxHf8FWfeQ2JHFCDJNYCY50WUBv feL9NvaVmSorDPoQJp5y4QEjqHGokXlo2RbQOOuJGTqniGVnPS0Iyxi676kuEL77bGNz AJO0p8hUSg2Tq5WoVMn5QI0WLu/1BfZs2pdKwE4z4l1BX4Zd+GEPGIKYKsuaFaRWC1zQ OMkA==
X-Gm-Message-State: APjAAAVC/MPvK1++KElq1SgJ5coPZR0wRkGzT6P1pBca5mpcNx0TUhly lxsX6o5/77U7BpfCBR7r6WRXZd6qsFD0jaucw77GXQ==
X-Google-Smtp-Source: APXvYqwZM08QRQlw21ZLfZK5AOxBR2g+4SHGy0Vi2JYFAQUcVMeu+pxzMWu1Okzv85/sSgVPLpdHdc6ipxoC1ie8vKE=
X-Received: by 2002:a17:906:69c4:: with SMTP id g4mr19713479ejs.9.1562640716338; Mon, 08 Jul 2019 19:51:56 -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>
In-Reply-To: <132b2c1168af4abca668a32db664d2a2@ustx2ex-dag1mb5.msg.corp.akamai.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 8 Jul 2019 19:51:44 -0700
Message-ID: <CALx6S34diayXCMPz-59V9+mpOGzNjqi8x6POfE6Lxgb+9f-qeQ@mail.gmail.com>
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, tsvwg <tsvwg@ietf.org>, "isabelle.hamchaoui@orange.com" <isabelle.hamchaoui@orange.com>
Content-Type: multipart/alternative; boundary="000000000000cf2d70058d36a4cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qiCPOc3O_fzC9nlEDIIHHs33Ors>
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, 09 Jul 2019 02:52:00 -0000

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