Change:
This PR is purely editorial and does not change the protocol in any way. When we discussed in Cupertino, it emerged that there was consensus for this editorial change but not for all topics in that issue, so I split this out to its own PR.
So the variable length integers have a 2 byte length prefix followed by a two bit length encoding?
Are we doing URL here or not?
NAME this is an editorial PR that does not change any wire encoding. We are not doing here.
This not marked as editorial. It was decided in Cupertino to either do here or to
NAME that is not my recollection. Either way, this is a PR, we can discuss non-editorial changes on the appropriate issue.
As of , transport parameter identifiers are 16bit integers, with a registry where uses the is reserved for experimentation While keeping Specification Required makes sense for a good chunk of the registry space, I think there will be many experiments that are conducted before a full specification is written (some already exist today and I expect there to be many many more once the protocol is standardized). However, those experiments only have 256 values to play with, and that is bound to cause collisions and headaches down the road. I think the simplest solution to this problem is to use variable length integers for transport parameter identifiers. The TLS presentation language doesn't support them but since we already use VLIs for the values of several transport parameters we're no longer bound by the TLS presentation language. I think there was also support for doing this when it was discussed on , but that issue was closed when the values were changed to VLI with , without changing the identifiers. I'm happy to write the PR if this issue gathers support.
You aren't the first to suggest this one. Let's make sure we at least discuss this directly. We did discuss this in the context of the issues that you cite and decided not to, but that was never the central question. From our perspective, this isn't a significant change to code.
The same for us, too. Am I understanding correctly that the concern here is that extensions of TLS structures tend to use uint16_t as their type identifiers, and that the reusable parser might be constrained to that design pattern?
I thought that this might be the case originally, but it turns out that the blob for transport parameters is generated by QUIC code in mostly all of the cases I have seen. If there is someone out there who is relying on passing a TLS stack a structured grammar and letting the TLS stack perform serialization, then we might want to just leave this alone.
Thank you for the clarification. We do use the TLS stack to encode / decode the transport parameters, therefore we do want see the TLS grammar-based design being preserved. The reason we do not mind the extension type being a varint is because our codec is flexible enough to handle that. URL
We should definitely do something to increase the number of experimentation codepoints from 256. Changing to a varint sounds good. If not, then we should allocate more of the space(ie: [0xf000 - 0xffff]) to experiments.
I agree with NAME and I don't think we need to go varint here, that seems like a bit of an overkill. How about reserving 4096 codepoints for spec required, and leaving the rest (2^16 - 2^12 = 61440) for experimentation: [0x0000 - 0x0fff] uses the RFC8128 Specification Required policy [0x1000 - 0xffff] is reserved for experimentation
Apart from the fact that we want to limit changes at this stage, are there arguments against going varint here? It feels pretty odd that many transport parameters are TLVs where T and L are 16bit and V is varint.
I don't have much of an argument here besides the general principle that we shouldn't provide more flexibility than is necessary. I don't think it's odd that T is fixed-length while the V is varint, FWIW. If no implementations are bothered by the change to varint, then it's a bit of a bikeshed. Let's see if other implementers are bothered.
Split in two ? what the same size ? Don't forget there is also GREASE TP now
From looking at all the integer fields in QUICv1, it looks like at this point everything is a varint except the versions, packet numbers, connection ID lengths (which all have valid reasons for their lengths), and the transport parameter identifier and transport parameter lengths. Switching transport parameters to QUIC format (as opposed to TLS presentation language) feels fitting to me, saves bytes on the wire, and will facilitate innovation down the road.
I'm happy to make transport parameter identifier a varint. NAME Are you(implicitly) suggesting that transport parameter lengths should be varint as well?
I think so, yes. If we're changing implementations might as well make both changes at once (assuming no one wants one of them to be varint but not the other).
I'd be opposed to changing the transport parameter lengths to varints, as that means departure from the TLS notation that we use for defining TPs. It's very different from changing the IDs to varints, which is just changing the type of a particular variable. IIRC, we discussed if we should switch to a different notation, and decided to go with the TLS-based design. At least I have built (or maintained) code based on that.
I agree with Kazuho here: splitting it in half would make plenty of room
I'm in favor of the change that NAME is suggesting in . There's no reason for us to use TLS presentation language, if anything, it just makes the spec harder to read for people who are unfamiliar with the TLS presentation language (if I remember correctly, this came up multiple times on issues here and / or on Slack).
Remember the experience with the X-Options in SMTP or HTML? Do we really want to replicate that?
Discussed in Cupertino. NAME to open a new Editorial issue to only replace the TLS syntax with something easier to understand. NAME to also do a Design PR to shuffle the assigned ranges in the registry.
As discussed in Cupertino, I have closed previous PR and replaced it with: editorial-only PR IANA policy PR
I think that the RFC 6648 lessons need to be considered carefully here. I think that it would be better to use a combination of random selection and provisional registration as a means of handling experiments. Random selection means that we end up colliding with very low probability; provisional registration ensures that registrations are protected. Making the private use space larger does neither. I would prefer to instead remove the private use space completely.
SGTMLGTM. I'd also be for removing the unnecessary, prefixed and fine with changing to varint encoding where applicable.

Discussion:
use a CONNECTION_CLOSE frame if it has sufficient state to do so. To support this process, a token is sent by endpoints.  The token is <del> carried in the NEW_CONNECTION_ID frame sent by either peer, and servers can specify the stateless_reset_token transport parameter during the handshake (clients cannot because their transport parameters don't have confidentiality protection).  This value is protected by encryption, so only client and server know this value. Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </del> <ins> carried in the Stateless Reset Token field of a NEW_CONNECTION_ID frame.  Servers can also specify a stateless_reset_token transport parameter during the handshake that applies to the connection ID that it selected during the handshake; clients cannot use this transport parameter because their transport parameters don't have confidentiality protection.  These tokens are protected by encryption, so only client and server know their value.  Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (frame-retire-connection-id). </ins> An endpoint that receives packets that it cannot process sends a packet in the following layout:

packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset <del> Tokens that are associated with connection IDs that the endpoint recently used to send packets from the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from </del> <ins> Tokens corresponding to active connection IDs that the endpoint has used for sending packets to the IP address and port on which the datagram is received.  This includes Stateless Reset Tokens from </ins> NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have

that is reset by revealing the Stateless Reset Token MUST NOT be reused for new connections at nodes that share a static key. <del> The same Stateless Reset Token MAY be used for multiple connection IDs on the same connection.  However, reuse of a Stateless Reset Token might expose an endpoint to denial of service if associated connection IDs are forgotten while the associated token is still active at a peer.  An endpoint MUST ensure that packets with Destination Connection ID field values that correspond to a reused Stateless Reset Token are attributed to the same connection as long as the Stateless Reset Token is still usable, even when the connection ID has been retired.  Otherwise, an attacker might be able to send a packet with a retired connection ID and cause the endpoint to produce a Stateless Reset that it can use to disrupt the connection, just as with the attacks in reset-oracle. </del> <ins> The same Stateless Reset Token MUST NOT be used for multiple connection IDs.  Endpoints are not required to compare new values against all previous values, but a duplicate value MAY be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Note that Stateless Reset packets do not have any cryptographic protection.

eliciting packet.  This recommendation is in keeping with standard practice for TCP RFC5681. <del> A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the "max_ack_delay" transport parameter.  This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received.  The sender can use the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission. </del> <ins> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.  The sender uses the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY. </ins> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet

determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. <del> Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed, to complete the handshake with minimal latency. Delaying them by a small amount, such as the local timer granularity, allows the endpoint to bundle any data sent in response with the ACK frame.  ACK frames SHOULD be sent immediately when the crypto stack indicates all data for that packet number space has been received. </del> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING frames might cause the sender to become limited by the congestion

processed.  An endpoint MUST NOT include delays that is does not control when populating the Ack Delay field in an ACK frame. <del> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used. </del> 13.2.6. ACK frames MUST only be carried in a packet that has the same packet

18. <del> The format of the transport parameters is the TransportParameters struct from _figure-transport-parameters.  This is described using the presentation language from Section 3 of TLS13. </del> The "extension_data" field of the quic_transport_parameters extension <del> defined in QUIC-TLS contains a TransportParameters value.  TLS encoding rules are therefore used to describe the encoding of transport parameters. </del> <ins> defined in QUIC-TLS contains the QUIC transport parameters.  They are encoded as a length-prefixed sequence of transport parameters, as shown in transport-parameter-sequence: The Sequence Length field contains the length of the sequence of transport parameters, in bytes.  Each transport parameter is encoded as an (identifier, length, value) tuple, as shown in transport- parameter-encoding-fig: The Transport Param Length field contains the length of the Transport Parameter Value field. </ins> QUIC encodes transport parameters into a sequence of bytes, which are then included in the cryptographic handshake.

The server's preferred address is used to effect a change in server address at the end of the handshake, as described in <del> preferred-address.  The format of this transport parameter is the PreferredAddress struct shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are encoded in network byte order. </del> <ins> preferred-address.  The format of this transport parameter is shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family.  IP addresses are encoded in network byte order.  The CID Length field contains the length of the Connection ID field. </ins> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes only connection