Re: [Plus] Blog post on quic and tou

[Brian Trammell <[e-mail]>]

hi Jana,

(inline, trimmed where appropriate)

> On 08 Dec 2016, at 18:39, Jana Iyengar <[e-mail]> 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