Do servers need to understand compatibility?

[DavidSchinazi]

If there is a definition for a mapping from vM to vN, can a client assume that the server will understand that mapping? Or does the client have to accept an incompatible version negotiation from servers?

It would be nice if compatible mappings could be developed separately from QUIC versions, which suggests that the server can decide whether to apply the mapping.

(Issue copied from individual draft repo, by @martinthomson on 2019-11-12)

[DavidSchinazi]

Copy of the conversation from the original issue:

@ekr

Can you say more about "mapping"? I don't believe that appears in this document, so I'd like to make sure we are on the same page.

@martinthomson

Sorry, I was using my own model. If you can use an initial flight from A to negotiate B (i.e., there is a mapping from that flight in A to the equivalent in B), then can the client expect that the server will understand that the two are compatible?

I think that the inclusion of a list of compatible versions in the transport parameter implies that there is a need for a shared understanding of what is compatible. However, I don't think that is necessary.

@ekr

So, say hypothetically we have version A and B, which are the same except that B uses a different code point for the CRYPTO frame. And so in principle, the client could send an Initial with version=A, compat_versions=[A, B] and the server could respond with B, but for some reason the server vendor doesn't realize this and instead sends VN = B?

@martinthomson

Right. I don't know if this has implications for design, but it came up in our discussion of what ALPN applies to this morning.

@DavidSchinazi

Perhaps we should state that for two versions to be compatible, there MUST be a document defining this mapping? But we need to handle the case where client believes A maps to B but the server doesn't know about this happing and sends a VN packet - the client needs to be OK with that?

@martinthomson

Right. I think that clients need to be willing to accept version negotiation always. A server might not implement mappings or might only support trivial mappings.

@ekr

Hmm.... I'm not sure I buy this. In other protocols (e.g., TLS), we don't have VN at all and just expect servers to properly implement the version negotiation mechanism, and there just isn't confusion about what's compatible. I agree we've had intolerance problems, but given that TLS negotiation is simpler than QUIC negotiation, it's not clear that falling back to VN will reduce those.

@martinthomson

I see. You are concerned that clients being willing to accept VN will result in downgrades, even if they are only performance downgrades (you get the same end result, but with worse performance). Can't we address that with post-hoc validation of the version parameters?

You can make part of the definition of B a requirement to understand a mapping from A, but if the mapping is defined separately, then you can't insist on the mapping being understood.

@ekr

That's not my primary point. Rather, it just seems like this is creating a
bunch of unnecessary confusion

[MikeBishop]

I believe clients always have to accept the incompatible-version path. If the client offers A and knows that a mapping from A to B exists, that doesn't mean the server possesses that mapping. From the server's point of view, if it only implements B, it's receiving a packet offering an unknown version. It will send a VN packet, and expect the client to retry with B.

The only way around that is if the client also knows that the spec for B requires supporting a mapping from A. I don't think we can assume that's the general case, though it might happen in some cases.