Reducing ossification through protocol design (was Re: Packet number encryption)

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

hi Roberto, all,

(trimming CC, forking thread, since this *really* is separate from the question of packet number encryption.)

> On 3 Feb 2018, at 19:37, Roberto Peon <[e-mail]> wrote:
> 
> Ossification:
> In the past tcp middleboxes expected in-order, monotonically increasing offsets and tried to fix reordering before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more efficient.
> 
>  This is the kind of non-theoretical ossification that drove the creation of QUIC in the first place.

This becomes more theoretical when you apply observations about TCP to QUIC:

(1) Sequence numbering in TCP is far more broken than packet numbering (encrypted or not) ever could be, simply because it's not end-to-end integrity protected. The first deployed sequence number meddling boxes, IIRC, were designed to randomize ISNs (i.e., rewrite them), since stacks that did so were slow to deploy. PN rewriting is not only useless in QUIC, it'll break the connection.

(2) Many TCP stacks actually had (and some have) crap performance under certain reordering patterns, such that the deployment of a middlebox that did "fix" reordered packets would have had measurable benefits when tested against the stacks prevalent on the networks on which they were deployed at the time they were deployed. A QUIC PN-reordering middlebox would not show any such benefit, and would be correspondingly difficult to sell.

(3) The time to "path interference decay" for the TCP sequence number was years. Yes, things move more quickly now (indeed, as evidenced by experience with GUIC), but unless we intend not to deploy QUIC version 2 rapidly on the heels of QUIC version 1, I would submit that there's still time to revise everything not in the invariants. (And, indeed, if we do *not* intend to deploy QUIC version 2 rapidly on the heels of QUIC version 1, i.e., not until the "path interference decay" time, then this entire exercise is academic and we can all go home, because the version negotiation mechanism will ossify, greasing or not.)

I think we need to take a step back and take a more systematic view toward ossification prevention.

Greasing, in the TLS sense, refers to not allowing extensibility codepoints to have a single value or set of values that can be used for traffic classification and/or bad traffic rejection by a naive device on the path. This is useful when you're trying to keep parts of the codepoint space available for future use, but the design of QUIC is such that the set of codepoints *in the wire image* is completely determined by the negotiated version; i.e., adding a new packet type to the QUIC long header would require a new version. Therefore, protecting the version negotiation mechanism itself is necessary and sufficient to prevent the wire image from ossifying.

This points the way to an alternate approach which will free us from having to have the ossification discussion about every single bit in the Version 1 header. Early and meaningful exercise of the version negotiation mechanism, with at least two versions whose wire images have *only* our intended invariants in common, is far superior to greasing the version codepoints as a method to protect the version negotiation mechanism. Greasing is a way to "fake" agility when you don't have any real agility yet -- but we're designing a protocol with real agility, with a version negotiation mechanism based at least in its core operation on GUIC's mechanism -- i.e., on one which we know at least one deployer of the protocol has used successfully multiple times.

Greasing is still useful for fields in the invariants that have static values for codepoints we might want to use in the future -- but the greasing space should cover the whole codepoint space in these cases, since post VN we know which values are grease.

(The PN encryption question is separate. The fundamental question here is "should the path see the PN?"... before Melbourne, the answer was "it doesn't matter because we haven't figured out a scalable way to do that". Now the answer is "probably not the whole PN, but the bottom N bits seem quite useful for maintaining TCP-equivalent measurability for the protocol, with a linear linkability risk / measurement utility tradeoff depending on N." Those N bits ossify only if Version 1 is the only QUIC version for the foreseeable future, or if we put them at the same observable offset in the Version 2 header.)

Cheers,

Brian