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

Tom Herbert <> Tue, 09 July 2019 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E57612004C for <>; Mon, 8 Jul 2019 17:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hg64bJQoqJUD for <>; Mon, 8 Jul 2019 17:20:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C16A212001E for <>; Mon, 8 Jul 2019 17:20:08 -0700 (PDT)
Received: by with SMTP id e2so9329544edi.12 for <>; Mon, 08 Jul 2019 17:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Hm8FnmRmx7RL1T+BRCW3i4maZlp1xj5twxy9PNf/F0o=; b=hapyZIxt1IUNifFedvqpEAmNwJCVJQY/KlPzregmHTegexRfQQrzSqgof1uD1yKKYm 6ebXqtAd68g52bZqMW0k40v7Rj/sfIBEF4UZyrMZ7kbQK5zeAkH+wQAESb9IQ23L2OHO 31QPC09onTzsteXsOLqJz7a8wn2MiCPn3jG4Zy6ioDCshq6HVFPVyrX0106qgQof+gzb +GqZwCvxbfRmHBJUzsRrAzVnspX2Rq+u+jI5oHAnw0wDX3DL/QtzMMVDAzfOJBKVQy+E VgYUW93tVwJuVPsI8cCDO5e408o+jMNjS7ZfjUpTVNwBPQuWOa2SPxNBc1M5qnNymqCq 9DKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Hm8FnmRmx7RL1T+BRCW3i4maZlp1xj5twxy9PNf/F0o=; b=WHZ2C3mzOkCn3OepGFazepNFhjZtU0XDOpNsBwNH0UgY+rGSQtRdPCpfVguSMgq6E1 AODAtL4lLZamD5fkmw2vQJrEk8D0hFLdK9SMFQ8YOqf/BqSw0TK7GtjNEv4qZu8GrRLN jbtTtvuDIBZeIEPZPVnX2o5mLW61v4v9tuMgZIz3PAF7GoNZCBLGUNMy7kTWEiW83nq7 7S1aByPWzDIg6GY+aXMEAMHfW6Br8D/kuimUiUivXC6yIQIXwThCMi1pX8CcfRFk5koy qqJkLkJp0WE/l0I/6dDfdzTtSmD+9mgr1JREu+qgwYKl3FDyDyddj2EGJesBBMZYddx4 rixw==
X-Gm-Message-State: APjAAAW50XO4XYDjAn6QwezNvsgjLFRRk97TJ4N0ZdcaV7yNamAUJawB L6lKMRncQbYtCT3RwDEANYJDWrqBGR44zNKkgVPBFQJ56Eg=
X-Google-Smtp-Source: APXvYqwFuYe0+52z/LRh5ul26q5WDODOlH5ZJo1vLK33H8qSyie1Pho3z3SJNqNdXC6XJy03FE2Q4pFj1IPI++UufyA=
X-Received: by 2002:a17:906:fcb8:: with SMTP id qw24mr18974302ejb.239.1562631607085; Mon, 08 Jul 2019 17:20:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Mon, 8 Jul 2019 17:19:56 -0700
Message-ID: <>
To: "Lubashev, Igor" <>
Cc: "" <>, Isabelle Hamchaoui <>, Alexandre Ferrieux <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Packet Loss Signaling for Encrypted Protocols: draft-ferrieuxhamchaoui-tsvwg-lossbits
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2019 00:20:10 -0000

On Mon, Jul 8, 2019 at 2:20 PM Lubashev, Igor <>; 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.


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?


> -----------------------------------------------------------------------------------------------------------------------------------------------
> 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:  
> Status:
> Htmlized:
> Htmlized:
> 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.