Re: [Plus] Blog post on quic and tou

Brian Trammell <ietf@trammell.ch> Thu, 08 December 2016 20:40 UTC

Return-Path: <ietf@trammell.ch>
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 8EF201296C9 for <plus@ietfa.amsl.com>; Thu, 8 Dec 2016 12:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level:
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2Y_BPPdhi682 for <plus@ietfa.amsl.com>; Thu, 8 Dec 2016 12:40:12 -0800 (PST)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D62061296CB for <plus@ietf.org>; Thu, 8 Dec 2016 12:40:07 -0800 (PST)
Received: from [10.0.27.103] (dynamic-94-247-222-033.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 46F951A00B8; Thu, 8 Dec 2016 21:40:06 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_8B59904D-7909-4E3A-A525-5BA65773307D"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <CAGD1bZZMTEeJ+07Y90vXE6j1yWTdDqPQ2-tWy-gNJSoNFaWsZg@mail.gmail.com>
Date: Thu, 8 Dec 2016 21:40:05 +0100
Message-Id: <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>
To: Jana Iyengar <jri@google.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/buWJpr6c8AtZzeX_6bWt13lfgIk>
Cc: plus@ietf.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
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: Thu, 08 Dec 2016 20:40:14 -0000

hi Jana,

(inline, trimmed where appropriate)

> On 08 Dec 2016, at 18:39, Jana Iyengar <jri@google.com> wrote:
> 
> Hi Brian,
> 
> I'm largely in agreement; a couple of thoughts inline.
> 
>> One requirement from that list that seems quite useful, though I don't know how to solve in the general case or in QUIC specifically: "determine [if] the software on the client or the server is the bottleneck". This is a very common triage task in network operations: does this problem indicate a misconfiguration of my network, or (more cynically) can I demonstrate that it's not my fault and therefore not my problem? Requiring access to one or both endpoint machines to answer that... seems like a question for a future Internet architecture research project.
>> 
> This can be done by measuring at ingress and egress. A simplistic design, at a high level, is:
> (i) use packet number / ack number to measure queue buildup and loss downstream of the ingress point, measured at the ingress.
> (ii) use packet number / ack number to measure queue buildup and loss downstream of the egress point, measured at the egress.
> (iii) subtract (ii) from (i) to find queue buildup and loss in the network.
> 
> That at least gets you as far as identifying the problem as in the network or outside it.

This requires a few properties, all of which would be satisfied by a QUIC that exports a packet number that always increments by one, even for zero-payload and packets with retransmitted frame (which I note it does unless I'm reading wrong), and exported an ack number that's really more of a "max packet number echo" (since the heuristics to make this work with TCP require you to ignore ACKs under loss conditions). (A delta term

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

>> My (possibly starry-eyed optimistic) hope is that a deliberately designed wire image will create a path of least resistance for middlebox designs to (reactively) follow. A well-designed wire image should be so obvious that the in-network reaction will be the one desired by the designers evenfor middleboxes built by people who didn't read the spec.
> 
> 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.

Cheers,

Brian