Version Negotiation and MTU

[gloinul]

In Section 5.3 of -03 of the draft:

The payload of the Version Negotiation packet is a list of 32-bit
versions which the server supports, as shown below.

As this is an open ended number of versions out of the version number space that actually is very large. Considering that this is an packet sent when no state may exist about MTU, this needs to be limited to keep into safe levels. The general recommendation in later section is to limit full packet to below 1280 bytes. That is 1232 bytes for QUIC headers, and there are 16 bytes before this list. Thus, there is a maximum of 304 versions that fits. Not an immediate problem, but some hint to that there are a limit to N, might be valuable.

[martinthomson]

To a large extent, I think that this problem solves itself. That is, all the incentives are aligned to keeping the packet small. I see no reason not to mandate a limit on the packet size though (less than the packet size that it is generated in response to would be fine).

[gloinul]

Agree this is more an editorial issue, than actually being a significant design issue. I think there is a point to note that the practical upper limit to N is MTU limitations, and the need to have all the versions implemented.

[martinthomson]

Yeah, I think that we can solve this easily, but deciding on a size turns out to have interop implications. I'm being cautious.