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

[ianswett <[e-mail]>]

ianswett commented on this pull request.



> -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 contain an entire
+crytographic handshake message, which for TLS is the ClientHello.  Though a
+packet larger than 1200 octets might be supported by the path, a client improves
+the likelihood that a packet is accepted if it ensures that the first
+ClientHello message is small enough to stay within this limit.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the

I think the first "overheads" is unnecessary and the second can be "overhead"

> -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 contain an entire
+crytographic handshake message, which for TLS is the ClientHello.  Though a
+packet larger than 1200 octets might be supported by the path, a client improves
+the likelihood that a packet is accepted if it ensures that the first
+ClientHello message is small enough to stay within this limit.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses a connection
+ID without zero length, nor does it include the token or a connection ID longer

nor does it -> and does not

> -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 contain an entire
+crytographic handshake message, which for TLS is the ClientHello.  Though a
+packet larger than 1200 octets might be supported by the path, a client improves
+the likelihood that a packet is accepted if it ensures that the first
+ClientHello message is small enough to stay within this limit.
+
+QUIC packet and framing overheads add at least 36 octets of overheads to the
+ClientHello message.  That overhead increases if the client chooses a connection
+ID without zero length, nor does it include the token or a connection ID longer
+than 8 octets that might be required if a server sends a Retry packet.

This sentence is long, maybe a comma after "octets"

> +ID without zero length, nor does it include the token or a connection ID longer
+than 8 octets that might be required if a server sends a Retry packet.
+
+A typical TLS ClientHello can easily fit into a 1200 octet packet.  However, in
+addition to the overheads added by QUIC, there are several variables that could
+cause this limit to be exceeded.  Large session tickets, 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 can have an effect on a client's ability to connect.  Minimizing the
+size of these values increases the probability that they can be successfully
+used by a client.
+
+A client is not required to fit the ClientHello that it sends in response to a

Is this because HRR is assumed to be stateful?

> @@ -3629,19 +3629,24 @@ The details of loss detection and congestion control are described in
 The QUIC packet size includes the QUIC header and integrity check, but not the
 UDP or IP header.
 
-Clients MUST pad any Initial packet it sends to have a QUIC packet size of at
-least 1200 octets. Sending an Initial packet of this size ensures that the
-network path supports a reasonably sized packet, and helps reduce the amplitude
-of amplification attacks caused by server responses toward an unverified client
-address.
+Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP

MUST pad to ensure?

> @@ -3629,19 +3629,24 @@ The details of loss detection and congestion control are described in
 The QUIC packet size includes the QUIC header and integrity check, but not the
 UDP or IP header.
 
-Clients MUST pad any Initial packet it sends to have a QUIC packet size of at
-least 1200 octets. Sending an Initial packet of this size ensures that the
-network path supports a reasonably sized packet, and helps reduce the amplitude
-of amplification attacks caused by server responses toward an unverified client
-address.
+Clients MUST pad ensure that the first Initial packet it sends is sent in a UDP
+datagram that is at least 1200 octets. Padding the Initial packet is a good way
+to ensure this, though including a 0-RTT packet in the same datagram is also a

How about: "Padding the Initial packet or including a 0-RTT packet in the same datagram are ways to meet this requirement."  Feel free to add good if you want, but that seems unnecessary.

>  
-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 the first Initial packet from a client MAY exceed 1200
+octets if the client knows that the Path Maximum Transmission Unit (PMTU)

knows -> believes

-- 
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-136243347