Version field <-> Version is not invariant #3785
Conversation
...it's just a Version field. This is a subtle one, but it follows from the work that others have been doing on greasing versions or providing additions to echconfig for QUIC connection establishment. It basically says that Version is for endpoints, not middleboxes.
martinthomson
added
editorial
martinthomson
added
design
|
I like the idea here, but it seems like the distinction in the text is too subtle. Why not remove this entirely? |
|
By "this", do you mean striking |
|
I was actually suggesting removing it from invariants entirely. |
|
I would quibble a bit about whether or not version aliasing really violates the existing text, but I still think this change is a good one. For example, if we fail to prevent ossification then we're going to end up with this being the "fake" version while the real version is buried in the TPs. |
draft-ietf-quic-invariants.md
Outdated
| @@ -252,8 +252,9 @@ Packets for the same QUIC connection might use different connection ID values. | |||
|
|
|||
| ## Version | |||
|
|
|||
| QUIC versions are identified with a 32-bit integer, encoded in network byte | |||
| order. Version 0 is reserved for version negotiation (see | |||
| The Version field contains a 32-bit integer, encoded in network byte order. | |||
There was a problem hiding this comment.
(If this is off-topic for this PR, please ignore.)
Is there a reason why we specify that the Version field is an integer, as opposed to a 32-bit value?
There was a problem hiding this comment.
Only so that we can use numbers to talk about values. TLS picked up this crazy {3, 3} notation that annoys the hell out of me. People read that to mean that there are two discrete things with different semantics, when there is just one value and one semantic. You could always write out the hex (as people now do for connection IDs), but then that's just a number.
There was a problem hiding this comment.
I definitely agree we don't want something like the TLS notation.
The only operation we need to do on QUIC versions (as encoded on the wire) is to check for equality. We don't need ordering of them (to check if one is less than another), and we certainly don't need to be able to do arithmetic on them, hence we don't need to consider them as numbers. By saying it's a 32-bit value (instead of an integer), we avoid needing to specify that it's network byte order. When specifying a version, you can write it out in hex (e.g. 0xff00001d), but that can be treated as a sequence of bytes instead of an integer.
There was a problem hiding this comment.
Would s/integer, .../identifier/ work for others?
There was a problem hiding this comment.
I personally like 32-bit identifier. 32-bit opaque identifier might be even better, or could be overkill.
There was a problem hiding this comment.
I'm fine with identifier.
draft-ietf-quic-invariants.md
Outdated
| QUIC versions are identified with a 32-bit integer, encoded in network byte | ||
| order. Version 0 is reserved for version negotiation (see | ||
| The Version field contains a 32-bit integer, encoded in network byte order. | ||
| This value can be used by endpoints to identify a QUIC Version. A Version field |
There was a problem hiding this comment.
If we end up with version ossification and the real version ends up in transport params, is it still the case that an endpoint can use the Version field to identify a QUIC Version? Perhaps "This value can be used by endpoints in identifying a QUIC Version" instead. That way there's room that an endpoint might consider other factors in identifying the QUIC Version used.
There was a problem hiding this comment.
Ahh, this gets into whether it is necessary or sufficient information to identify a QUIC version and whether we need to say anything more. "can" might be read to imply that it is sufficient, though "can" doesn't imply necessity. But "can" also means that it is possible for endpoints to use the field. That is the meaning I intended and I think that's OK.
There was a problem hiding this comment.
That wiggle room around "can" sounds good to me.
draft-ietf-quic-invariants.md
Outdated
| @@ -252,8 +252,9 @@ Packets for the same QUIC connection might use different connection ID values. | |||
|
|
|||
| ## Version | |||
|
|
|||
| QUIC versions are identified with a 32-bit integer, encoded in network byte | |||
| order. Version 0 is reserved for version negotiation (see | |||
| The Version field contains a 32-bit integer, encoded in network byte order. | |||
There was a problem hiding this comment.
I'm fine with identifier.
Identify VN using 0x00000000.
...it's just a Version field.
This is a subtle one, but it follows from the work that others have been
doing on greasing versions or providing additions to echconfig for QUIC
connection establishment. It basically says that Version is for
endpoints, not middleboxes.