Re: Measurement bit(s) or not

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 12 February 2018 09:35 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8551270A0 for <quic@ietfa.amsl.com>; Mon, 12 Feb 2018 01:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YAOEaUGDccZB for <quic@ietfa.amsl.com>; Mon, 12 Feb 2018 01:34:59 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 2937E120047 for <quic@ietf.org>; Mon, 12 Feb 2018 01:34:59 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id i144so5920385ita.3 for <quic@ietf.org>; Mon, 12 Feb 2018 01:34:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=1/0w7TLQwxWqqd+04RQ830aeUWQXDBkXD4XBE13ziZI=; b=Zg7ZCN+yCeJO8cjlvYY95nnww17Hl24mOrH7hSqHEt+X81gE1+uB9+pwbqsBTvohTK KvZ12aiLKyjD5heY7P2XMlMU0Uiz6nO/wEWVEZpNFwgB3xRVqnQkyv6oRMi1kfcXdPGH qUOF37l6XG7VymoesZRG4m51YFivqI1zJeCwwTV7SSBphyaEt+CQNtRbRJhOC9IBMc/p 8Rr5LAa+x9u1Dp6ivWBOSHpnjQaIxDLI7zqC5zcT40jfz0zm+gJ6e3IZbZNkQ+F+L1eX Ux04iXNqi7+ygRBM5xELCCdl/SGTjUUUPbIfxt+hzenjtCb+uZDWZIls53SG09ws338a yYbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=1/0w7TLQwxWqqd+04RQ830aeUWQXDBkXD4XBE13ziZI=; b=ekh83addkchvaihtKqRYyLTKMH4oaGiyo30+2enf5gXTGak+o9NYrq02ppNRbEiYDm EnHS1hggrziImuGRkQJ8bJafylzN3MGI4tZajb90h5QY83onk9tWQxhDO5BBEfx9Ygc8 ZRs7RpbgEFDgykRoZRqr9Qrl1uIHff1l8ixoWhi428V9FfWFq2Upmd15hN25iaGyB/8c uOONp6DADLfwLC9yB1+2wdN0qSj1fslQ8esf+mSQz5G4K6mwAIVybEvAoieMcHrR1Tou IsCMo9JTTrYbmmocsta2GMUAYysbKPdJiOfDzrXoHjMl5IYrMAQCuEMKlksMdFHBF35v 1CPQ==
X-Gm-Message-State: APf1xPDSSYd0RKe3LHExWZdf1Dm2axKd9yxTNXHzno9uLRDOpMf2UI3y bhUkl+khukPs1lxpVtA5gqW3LTn2F1Fp66cNEXU=
X-Google-Smtp-Source: AH8x2259xAZfSNKV/XdX51XGMXXHtp70wZ3dLm01hG06ie0rlpH3YdyBQjVcroWyEksjEYp494SVum9g67k0XrItB/s=
X-Received: by 10.36.46.23 with SMTP id i23mr4715517ita.55.1518428098458; Mon, 12 Feb 2018 01:34:58 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 01:34:57 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch>
References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <aa7a56d01f0a41fe9ad0fd9e61c54c50@usma1ex-dag1mb5.msg.corp.akamai.com> <CAN1APddOWZRF6FxiEcJ4MbOpMwxqHm9=LbMB92pVkdUJNMuMyQ@mail.gmail.com> <CAN1APdcTH=oHdf=wixJZXOCCXcaYKR1ZkJQLDpndRdehuKfvBA@mail.gmail.com> <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 12 Feb 2018 01:34:57 -0800
Message-ID: <CAN1APdcXQXn=mbTyArsJKnHRPQkCRPqaw6ZdCHTTNN3g9s=DfQ@mail.gmail.com>
Subject: Re: Measurement bit(s) or not
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, "quic@ietf.org" <quic@ietf.org>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>
Content-Type: multipart/alternative; boundary="001a114a9d826cfa110565009711"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7m5PT_rUJdHRwQVoeKGXC6BVRaQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Feb 2018 09:35:01 -0000

On 12 February 2018 at 10.20.16, Brian Trammell (IETF) (ietf@trammell.ch)
wrote:

Do we want to do this?

Rephrased: Is the passive measurability of loss, reordering (and, if we
consider the spin bit as one of the measurement bits, latency) of QUIC
important to us, or do we decide we can live with the negative pressure a
complete loss of visibility and an vast increase in diagnostic complexity
will place on deployment?

Originally I did not care much, but I think there is self-interest in
supporting some level of passive monitoring:

External hostile agents that can drop packets are more easily exposed,
hence monitoring is a deterrent.

Traffic shaping by an internet provider might be exposed more easily.
Internet providers might “accidentally” misplace some netflix packets.

Routers that experience faulty paths can more readily route traffic towards
higher fidelity path in terms of latency and loss.

Omitting monitoring might just add tunnel headers increasing overhead.

Clearly there is a privacy concern, and we should not expose unnecessary
details. Packets could be sorted against the applications interest. But
this can happen with tunnel headers. Latency cannot as easily be monitored
without help, but it is not that difficult either: measure timing between
packets and find a pause, then wait for traffic the other way.