Re: QUIC ossification

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

hi Ian, all,

> On 15 Feb 2019, at 02:22, Ian Swett <ianswett=[e-mail]> wrote:
> 
> I believe the concern is that a middlebox/etc will conclude that a certain range of versions are IETF standard versions and should be allowed and others are fine to block because they're experimental, thereby making the majority of versions largely undeployable.

So if I understand the proposal behind this correctly, then, there would be no segregation of the version number space (aside from "grease" and "nongrease"), the entire non-assigned version number space would be IANA-managed FCFS, and the IETF-standard versions would grab random codepoints out of that FCFS space at publication time?

That fixes the "middleboxes preferentially block experimental versions" problem, at the expense of maybe edging them toward blocking everything that isn't IETF-V1. 

This is of course assuming that middleboxes exist that have an incentive to block non-V1 versions while letting V1 versions through. I could maybe see firewalls with default-deny policies wanting to "offer" this, but I don't see why a box deployed to blocking any QUIC on purpose would need to be picky about version numbers. Given that the TCP fallback makes it connectivity-safe to block *all* QUIC while also gaining the "advantages" (from the middlebox PoV, with respect to wire-image accessibility and wire-image editability) of TCP, just turning QUIC off is easier than having to keep per-flow VN outcome state.

going back to a point Ted made on Thursday, though:

> As a personal opinion, I think we have enough semantic additions to do here that we don't need an artificial version which will have no natural driver of adoption.

+1 to this.

I think I've said this before, maybe multiple times: the only way to keep version negotiation from ossifying it is to use it for real. I'd argued for shipping v1 and v2 simultaneously, perhaps with different feature profiles (indeed, we even discussed using the spin bit as a version-differentiator to exercise VN, but this turned out to not work very well for spin-bit-and-connection-ID physics reasons). It seems we're not going to do that: we'll ship v1 and start work on v2 after that.

I observe that there's an ossification window for version negotiation that arises as a logical consequence of the process we're following: after v2 ships, if it sees wide deployment, version negotiation as a mechanism will be protected (yeah sure some lazy middleboxes might hardcode two version numbers, but see above for my skepticism about the likelihood of that). Until then, it will not (grease notwithstanding, but grease isn't real protection for VN because it's safe to ignore). 

The risk of VN breaking is a function of how long that window is, and how quickly middleboxes that understand QUIC versioning will deploy. Recent proposals (I forget the details, have been paying only cursory attention during my month off) to punt VN to version 2 in essence make a pessimistic bet about this risk: anything we can design will be broken by the time we try to use it, so let's design it later. 

I think if we care about designing VN into V1 that has a chance of working, though, being aggressive about shipping V2 is the only action under our control as a WG.

Cheers,

Brian