Explicit measurability in the QUIC wire image (was Re: Packet number encryption)

["Brian Trammell (IETF)" <[e-mail]>]

hi Ted,

(trimming, forking, #include apologies for google/apple mail shenanigans)

> On 6 Feb 2018, at 01:49, Ted Hardie <[e-mail]> wrote:
> 
> On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar <[e-mail]> wrote:
> I don't think we're converging here, so I'd like to try and encourage us to move towards it. I have my opinion, but I care more about forward progress at this point.
> 
> There are three designs so far:
> 1. Packet numbers as is, with random gaps around migration.
> 2. Packet numbers encrypted, as per Martin's PR.
> 3. Packet numbers encrypted, plus a small modulo sequence number somewhere.
> 
> The concrete ones here are (1) and (2).  I'm listing (3) but am not inclined to consider it seriously, since it's not concrete enough, (and I don't want more bits to be spent in the QUIC packet header if that's where this info goes.)
> 
> 
> If you'll forgive my saying so, evidence suggests that so many of the concrete aspects of such a proposal (where the bits would live, how many bits, etc.) would change over the lifetime of a proposal in this WG that any completely nailed down suggestion might as well be a blank sheet for all the bearing it would have on the final placement and length.

Heh. Indeed.

> The question is:  do we wish to expose a small sequence number to assist in network analysis and management, yes or no?

A friendly amendment to refine this question, since I think it presupposes too much about the shape and color of said blank sheet of paper: do we wish to expose a signal that is designed to meet the following requirements:

- assist in on-path detection and measurement of upstream packet loss
- assist in on-path detection and measurement or upstream packet reordering
- improve the passive measurement of RTT in the presence of reordering (i.e., fix the spin bit to work without the packet number)

We (without the encryption PR) already have a single (implicit) signal for these three requirements, but we can without too much thought already see a few ways to add an implicit signal back in, probably even using only bits vacated in the short header by making encrypted packet numbers use varint encoding.

+1 to Ted: if we could at least come to consensus as a WG that these requirements are important, then we can separate these two discussions. Let's reserve some bits in the header, let those of us who care about the shape of the measurement nybble go off and work on a concrete proposal, and move on.

Cheers,

Brian

> We can argue over the bike shed color after making the decision to build a shed; requiring the shed have a color before considering the question seems less productive to me than just answering the question.
> 
> Just my personal opinion, of course.
> 
> Ted
>