the design should be QUIC-version neutral

[kazuho]

Current design requires changes to specification and the program being deployed to the middleboxes, each time a new QUIC version is deployed.

To paraphrase, we are introducing the incentive for middlebox vendors to block unknown versions of QUIC to which they cannot provide bandwidth information (or give preferential treatment to some versions of QUIC to which they can provide bandwidth).

I think what we need to design is a bandwidth notification mechanism that is neutral to QUIC versions.

One way of achieving that goal would be to use the special version number solely for exchanging the bandwidth information (or for triggering rewrites). To give an example, and endpoints would exchange QUIC v1 packets as-is, but occasionally also send QUIC vXXXX packets which would be rewritten by the middleboxes.

[huitema]

I agree that we risk building an ossification vector. We converge on a mechanism in which we negotiate a "TRAIN" version, as in:

• client starts with version=1, send initial packet, transport parameters indicate support for version=TRAIN,
• server agrees to version=TRAIN, defined as "just like version 1 but with a different encoding of VN in long packets",
• intermediaries see version=TRAIN, replace with version=TRAIN(10mbps).

With that rule, we would need different version numbers for TRAIN(of Version1), TRAIN(of Version2), etc. But the intermediaries will only recognize TRAIN(version1). Thus ossification.

The desired solution would have something like:

• client starts with version=1, transport parameters indicate support vor V2 and V3, and also for the TRAIN mechanism.
• server accepts version 3, says so in transport parameters, and accepts to use the TRAIN mechanism.
• at some point, client and server send long header packets with version=TRAIN. These packets are decoded with the version selected.

For the handshake, I think that implies some kind a train handshake before sending VN=TRAIN. Something like:

• client starts with version=1, transport parameters indicate support or V2 and V3, and also for the TRAIN mechanism.
• server accepts version 3, says so in transport parameters, and accepts to use the TRAIN mechanism. This is carried in initial and handshake packets with version = 3.
• client decodes all that, then sends handshake packet with version = TRAIN.
• server receives that packet, knows that TRAIN (or variants) shall be decoded as if it were the negotiated version (3 in that example).
• server sees that the client has sent TRAIN packet, can send TRAIN packets itself.

[kazuho]

@huitema Thank you for your comments. I think we are almost on the same page.

The desired solution would have something like:

Considering that the endpoints are never going to use version=TRAIN for exchanging data, I think the version does not need to be covered by Compatible Version Negotiation. The only information each endpoint need to notify to the peer is that it can decode BANDWIDTH frames.

For the handshake, I think that implies some kind a train handshake before sending VN=TRAIN. Something like:

While we can define when version=TRAIN packets should be sent, I am not sure if it's worth defining.

I might argue that they can be sent at any moment, regardless of the peer having support for train. Doing so has no negative effect (modulo the cost of sending a packet that never gets used), while having the benefit of hiding endpoints' capabilities from getting exposed onto the network.

Endpoints that are capable of handling version=TRAIN packets will buffer the bandwidth information, and sends the BANDWIDTH frame once 1-RTT keys become available (and if the peer has sent the TP).