Re: [Plus] Blog post on quic and tou

[Juho Snellman <[e-mail]>]

Hi,

On 8 December 2016 at 21:40, Brian Trammell <[e-mail]> 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