Change Client Initial size to 1200 flat #685
Conversation
martinthomson
added
-transport
design
draft-ietf-quic-transport.md
Outdated
|
|
||
| The initial client packet SHOULD be padded to exactly these values unless the | ||
| The initial client packet SHOULD be padded to exactly 1200 octets unless the |
There was a problem hiding this comment.
Can you make clear that this is just the QUIC packet, not the headers.
draft-ietf-quic-tls.md
Outdated
| @@ -541,7 +541,7 @@ older than 1.3 is negotiated. | |||
|
|
|||
| QUIC requires that the initial handshake packet from a client fit within the | |||
| payload of a single packet. The size limits on QUIC packets mean that a record | |||
| containing a ClientHello needs to fit within 1197 octets. | |||
| containing a ClientHello needs to fit within 1165 octets. | |||
There was a problem hiding this comment.
To be clear, this 1165 number may change if we increase or decrease the amount of framing overhead QUIC adds. Are we ok about that?
There was a problem hiding this comment.
I'm OK with that. As long as we stop changing the overhead when we ship the spec.
There was a problem hiding this comment.
One q: How are you arriving at 1165 if the 1200 doesn't include IP + UDP? 1(type byte) + 8(conn id) + 4(packet number) + stream frame type byte(1) + stream id(1 byte) + ?
draft-ietf-quic-transport.md
Outdated
| the QUIC header and integrity check, but not the UDP or IP header. Sending a | ||
| packet of this size ensures that the network path supports an MTU of this size | ||
| and helps reduce the amplitude of amplification attacks caused by server | ||
| responses toward an unverified client address. | ||
|
|
||
| Servers MUST ignore an initial plaintext packet from a client if its total size |
There was a problem hiding this comment.
It'd be nice to come up with a consistent way of referring to this "total size" which does not include IP+UDP.
There was a problem hiding this comment.
"QUIC packet size" or "packet size" should do.
There was a problem hiding this comment.
As with the definition of bytes_in_flight for recovery, it's important to have a consistent definition of packet size. It looks like we're aiming for "size of packet without including IP + UDP headers", which seems great, but the current text may be ambiguous?
draft-ietf-quic-tls.md
Outdated
| @@ -541,7 +541,7 @@ older than 1.3 is negotiated. | |||
|
|
|||
| QUIC requires that the initial handshake packet from a client fit within the | |||
| payload of a single packet. The size limits on QUIC packets mean that a record | |||
| containing a ClientHello needs to fit within 1197 octets. | |||
| containing a ClientHello needs to fit within 1165 octets. | |||
There was a problem hiding this comment.
One q: How are you arriving at 1165 if the 1200 doesn't include IP + UDP? 1(type byte) + 8(conn id) + 4(packet number) + stream frame type byte(1) + stream id(1 byte) + ?
| @@ -1140,7 +1140,7 @@ max_packet_size (0x0005): | |||
| the endpoint is willing to receive, encoded as an unsigned 16-bit integer. | |||
| This indicates that packets larger than this limit will be dropped. The | |||
| default for this parameter is the maximum permitted UDP payload of 65527. | |||
| Values below 1252 are invalid. This limit only applies to protected packets | |||
| Values below 1200 are invalid. This limit only applies to protected packets | |||
There was a problem hiding this comment.
Can we somehow clarify this size is also without UDP + IP headers?
1200- all of that(15) - version(4) - fnv-1a(8), which I realize now is 29 and not 35 because I calculated the original number with FNV-1a 128. |
Closes #684.