Re: [Plus] Blog post on quic and tou

Juho Snellman <jsnell@iki.fi> Fri, 09 December 2016 09:05 UTC

Return-Path: <jsnell@gmail.com>
X-Original-To: plus@ietfa.amsl.com
Delivered-To: plus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE012A285 for <plus@ietfa.amsl.com>; Fri, 9 Dec 2016 01:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 PUaYuK7YWKgU for <plus@ietfa.amsl.com>; Fri, 9 Dec 2016 01:05:37 -0800 (PST)
Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 B679B12A280 for <plus@ietf.org>; Fri, 9 Dec 2016 01:05:37 -0800 (PST)
Received: by mail-io0-x244.google.com with SMTP id p13so5500866ioi.0 for <plus@ietf.org>; Fri, 09 Dec 2016 01:05:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vtdOpoM+ez1h8kPyGyk18EN1adLvyfnMkObPIr7Gwr0=; b=jqc3cz3rng8nltjcej3sb9MytdB4da/6hBFe8C4DZE8/cLHVw24Nozly6R3DvPnNNk 4wfR4VOasxaba2xSpNG6oChvjcE3VZKYyNoT76kWVmc41sYDj2KDUOTP4nKLrqILH04O sofN/KH0bNRTOHEbEVM5Rq8dN1bQB35Hst8cKEa2bjKT7SP1AH2lu2HjfbSPvfjFTON5 8P2mdvQmb/Slch/p3kPVUq3LGZNYOaLyVisHj9ftCl3bu9258BfFFR7w2JAYnKz28mQK yT3WYFR1vOge7abPPvH2ivrinnSPgktdwNSzQi9qIE8lg1heDm7K+VzO2/rHycJGSR9V huQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vtdOpoM+ez1h8kPyGyk18EN1adLvyfnMkObPIr7Gwr0=; b=CdJoZfZaYtXd7WfhvJKo8kobhwDdOEf0PdypheLgzr7Xx6mE9RWMe8KFDGiBLtb0JL 3cv6oJxq4xW2ItgbWvG7Ba/PYgmh8PwudrEGs0TeGYw3u9lyRLjeyr6Mh42kKSRQkaOV w4/YC+mzjuXP8tDyVEQ95LjnNg5WfiN8MHDRM4U8V//G31jdyY5ilXa+Qk8y08skzYvD ZOr99vWidG23ivtjU/8IVndChAFcM8ff5ePvx6fpjuth3JzgUp5/6kxB0iOFRvF7IB/g 4mxyobA/fR7t494JqB73pmA65dxlwccbF3yHyxwCSAfej0/NITJ2/4vavr1G/SEHeIRh KghQ==
X-Gm-Message-State: AKaTC03L5M6xtzxWH9EBPMjur2+39nCUoWZJ4AqRHVACf/SuaTB0aNIB/gbLgqfjetKhYu6KXD3IPHwOB1SyOg==
X-Received: by 10.36.104.146 with SMTP id v140mr5792254itb.65.1481274337028; Fri, 09 Dec 2016 01:05:37 -0800 (PST)
MIME-Version: 1.0
Sender: jsnell@gmail.com
Received: by 10.64.81.67 with HTTP; Fri, 9 Dec 2016 01:05:36 -0800 (PST)
In-Reply-To: <641657F3-1D8A-420E-94D4-19D5FAA61715@trammell.ch>
References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> <CAGD1bZaXto+fq9A806ME1bonZv0639Yu5yazyp_eeeOQemeNzw@mail.gmail.com> <E416974A-BF2C-4D24-B9CF-1591CAE8D6C2@trammell.ch> <CAGD1bZZMTEeJ+07Y90vXE6j1yWTdDqPQ2-tWy-gNJSoNFaWsZg@mail.gmail.com> <641657F3-1D8A-420E-94D4-19D5FAA61715@trammell.ch>
From: Juho Snellman <jsnell@iki.fi>
Date: Fri, 9 Dec 2016 10:05:36 +0100
X-Google-Sender-Auth: hyCFfxfAFfIe_4I-xC0b-5EBNLU
Message-ID: <CAMv0bsf=ynDhGckWH-nXdRd5WPE+zBQ7eiK-1a9LRR2=gBbf4g@mail.gmail.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary=001a1143ff7aac70830543360e28
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/8yOgtm9Lb5-45NO5kkFBU9q55O8>
Cc: Jana Iyengar <jri@google.com>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, plus@ietf.org
Subject: Re: [Plus] Blog post on quic and tou
X-BeenThere: plus@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 09:09:48 -0000

Hi,

On 8 December 2016 at 21:40, Brian Trammell <ietf@trammell.ch> wrote:
>
> Note that this is a two-point measurement methodology, which requires a
> far more elaborate measurement infrastructure than a one-point methodology,
> which basically just needs wireshark. The infrastructure requirements for
> diagnosis of a particular problem given a particular wire image are also a
> point to consider in the tradeoff space. (Or, more cynically again, as
> someone who's spent a lot of time building measurement infrastructures,
> thank you for pointing out a business opportunity. :) )
>

With measurements from all points in the network the encryption becomes a
non-issue anyway; we'd simply match up the packets between the traces. So
exposing information that's only useful in a multi-point context doesn't
seem all that compelling to me.

My experience is that there's a huge difference in the amount of effort
needed to get a single point trace vs. multiple traces. The first one has
basically no lead time, and can be just part of normal operating procedure
when investigating a problem report. The second tends to require careful
coordination across multiple groups, often a lead time of several days, and
gets routinely botched when traffic isn't being routed exactly as expected.
(I'm not aware of any easy to use tools for doing multi-trace analysis
either. That'd of course change if such tools become a necessity instead of
a luxury).

A packet number + ack number would indeed be the most useful thing to
expose, since it gives downstream RTTs and upstream packet loss. It doesn't
really do much for downstream packet loss though, which is a pretty
important component. For that, I think you'd want one of the following (in
order of preference):

- All the nack blocks
- The latest nack block
- The number of nack blocks
- A "this packet is a retransmission" bit in data packets. (Though this
would have other uses than just monitoring).
- A "there is at least one nack block" bit (this is weak enough that you'd
probably need a lot of heuristics)

After packet numbers, acks, and some kind of a reliable nack signal,
diminishing returns start to kick in, at least for the purpose of finding
network level problems.

I wouldn't be quite as cynical about client / server problems as you were,
though :) It's not simply a way to close a case as "not my problem"; it's
that it's easier and faster to prove a specific component is the problem
than to prove that the network as a whole isn't.

> The problem that remains is that once middeboxes react to certain bits,
> deployment of changes to those bits requires herculean effort, as we see
> with TFO. But this is exactly the tradeoff -- every bit that is exposed may
> help the operator, but loses agility.
>
> Agree here completely. This isn't a "problem", rather it indicates a hard
> requirement to keep that wire image as minimal as possible.
>

Sure. When writing that post, I wasn't aware there was a discussion about
having more information outside the encryption envelope. So the contrast
was between "everything readable" vs. "nothing is readable". Of course I'd
always love to have more data available :) But if there's a sweet spot that
exposes just enough information, that'd be great.

-- 
Juho Snellman