Re: [quicwg/base-drafts] Datagram 1200 (#1548)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.

Largely editorial nits.

> -However, there are several variables that could cause this limit to be exceeded.
-Implementations are reminded that large session tickets or HelloRetryRequest
-cookies, multiple or large key shares, and long lists of supported ciphers,
-signature algorithms, versions, QUIC transport parameters, and other negotiable
-parameters and extensions could cause this message to grow.
-
-For servers, the size of the session tickets and HelloRetryRequest cookie
-extension can have an effect on a client's ability to connect.  Choosing a small
-value increases the probability that these values can be successfully used by a
-client.
+QUIC requires that the first Initial packet from a client be sent in a single
+UDP datagram.  This places constraints on the first ClientHello message.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses connection
+ID without zero length, nor does it include the token or a connection ID longer

**a** connection ID with non-zero length, perhaps?

> -Implementations are reminded that large session tickets or HelloRetryRequest
-cookies, multiple or large key shares, and long lists of supported ciphers,
-signature algorithms, versions, QUIC transport parameters, and other negotiable
-parameters and extensions could cause this message to grow.
-
-For servers, the size of the session tickets and HelloRetryRequest cookie
-extension can have an effect on a client's ability to connect.  Choosing a small
-value increases the probability that these values can be successfully used by a
-client.
+QUIC requires that the first Initial packet from a client be sent in a single
+UDP datagram.  This places constraints on the first ClientHello message.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses connection
+ID without zero length, nor does it include the token or a connection ID longer
+than octets that might be required if a server sends a Retry packet.

longer than octets?

> -For servers, the size of the session tickets and HelloRetryRequest cookie
-extension can have an effect on a client's ability to connect.  Choosing a small
-value increases the probability that these values can be successfully used by a
-client.
+QUIC requires that the first Initial packet from a client be sent in a single
+UDP datagram.  This places constraints on the first ClientHello message.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses connection
+ID without zero length, nor does it include the token or a connection ID longer
+than octets that might be required if a server sends a Retry packet.
+
+With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet
+with ample space remaining.  However, aside from the overheads added by QUIC,
+there are several variables that could cause this limit to be exceeded.  Large
+session tickets or HelloRetryRequest cookies, multiple or large key shares, and

You say below that HelloRetryRequest-triggered ClientHellos are exempt from this restriction, so it might be less confusing to omit that from your list of examples.

> +
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses connection
+ID without zero length, nor does it include the token or a connection ID longer
+than octets that might be required if a server sends a Retry packet.
+
+With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet
+with ample space remaining.  However, aside from the overheads added by QUIC,
+there are several variables that could cause this limit to be exceeded.  Large
+session tickets or HelloRetryRequest cookies, multiple or large key shares, and
+long lists of supported ciphers, signature algorithms, versions, QUIC transport
+parameters, and other negotiable parameters and extensions could cause this
+message to grow.
+
+For servers, in addition to connection ID and tokens, the size of TLS session
+tickets and HelloRetryRequest cookie extensions can have an effect on a client's

Same.

> -signature algorithms, versions, QUIC transport parameters, and other negotiable
-parameters and extensions could cause this message to grow.
-
-For servers, the size of the session tickets and HelloRetryRequest cookie
-extension can have an effect on a client's ability to connect.  Choosing a small
-value increases the probability that these values can be successfully used by a
-client.
+QUIC requires that the first Initial packet from a client be sent in a single
+UDP datagram.  This places constraints on the first ClientHello message.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses connection
+ID without zero length, nor does it include the token or a connection ID longer
+than octets that might be required if a server sends a Retry packet.
+
+With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet

Given that 1200 is a minimum, not a maximum, it might be worth calling out that the datagram can be larger than 1200 if needed.

> +
+With these overheads, a typical TLS ClientHello can fit into a 1200 octet packet
+with ample space remaining.  However, aside from the overheads added by QUIC,
+there are several variables that could cause this limit to be exceeded.  Large
+session tickets or HelloRetryRequest cookies, multiple or large key shares, and
+long lists of supported ciphers, signature algorithms, versions, QUIC transport
+parameters, and other negotiable parameters and extensions could cause this
+message to grow.
+
+For servers, in addition to connection ID and tokens, the size of TLS session
+tickets and HelloRetryRequest cookie extensions can have an effect on a client's
+ability to connect.  Choosing a small value increases the probability that these
+values can be successfully used by a client.
+
+A client is not required to fit a ClientHello that is sent in response to
+HelloRetryRequest in a single UDP datagram.

Consistency nits:
- You use "a" before other TLS handshake messages, so "**a** HelloRetryRequest"
- You use "fit into" elsewhere, but "fit ... in" here.

>  
-An Initial packet MAY exceed 1200 octets if the client knows that the Path
-Maximum Transmission Unit (PMTU) supports the size that it chooses.
+The datagram containing an Initial packet MAY exceed 1200 octets if the client

Since we're still talking about "the first Initial packet [the client] sends," perhaps "the first" or "this" instead of "an"?

>  
 A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet smaller than 1200 octets. It MUST NOT send any
-other frame type in response, or otherwise behave as if any part of the
-offending packet was processed as valid.
+response to an Initial packet contained in a UDP datagram that is smaller than

...but only if it's the first Initial packet on the connection, right?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1548#pullrequestreview-136099506