From 35b28e13aa41ebc53b3e053a8b52868bfb81a8e8 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 16 Jul 2020 11:11:53 -0400 Subject: [PATCH 1/4] Clarify how to represent the packet number if no ACKs have been received I noticed the 0-RTT specific text in #3914 and thought a general clarification would be better. --- draft-ietf-quic-transport.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 716d0f668b..9375d10bd1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4251,6 +4251,9 @@ arrives after many higher-numbered packets have been received. An endpoint SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards. +Prior to any acknowledgements being received for a packet number space, there is +no largest acknowledge packet, so the full packet number is encoded in the header. + As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous unacknowledged packet numbers, including the new packet. @@ -4607,11 +4610,7 @@ used for any new packets that are sent; as described in {{retry-continue}}, reusing packet numbers could compromise packet protection. A client only receives acknowledgments for its 0-RTT packets once the handshake -is complete. Consequently, a server might expect 0-RTT packets to start with a -packet number of 0. Therefore, in determining the length of the packet number -encoding for 0-RTT packets, a client MUST assume that all packets up to the -current packet number are in flight, starting from a packet number of 0. Thus, -0-RTT packets could need to use a longer packet number encoding. +is complete. A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server. This means that 0-RTT packets cannot contain any response to From b029ae61e52c7d7beb1bc751ed0843d5095d4490 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 16 Jul 2020 11:28:06 -0400 Subject: [PATCH 2/4] Update draft-ietf-quic-transport.md --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9375d10bd1..e2d6bb6366 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4252,7 +4252,8 @@ SHOULD use a large enough packet number encoding to allow the packet number to be recovered even if the packet arrives after packets that are sent afterwards. Prior to any acknowledgements being received for a packet number space, there is -no largest acknowledge packet, so the full packet number is encoded in the header. +no largest acknowledge packet, so the full packet number is encoded in the +header. As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous unacknowledged packet From f009224fcd784f2e5ea88bdb11dcdb4adfb0badd Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 20 Jul 2020 12:39:00 -0400 Subject: [PATCH 3/4] Martin's suggestion --- draft-ietf-quic-transport.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e2d6bb6366..a65cc27c80 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4243,17 +4243,17 @@ only the least significant bits of the packet number. The encoded packet number is protected as described in Section 5.4 of {{QUIC-TLS}}. -The sender MUST use a packet number size able to represent more than twice as -large a range than the difference between the largest acknowledged packet and -packet number being sent. A peer receiving the packet will then correctly -decode the packet number, unless the packet is delayed in transit such that it -arrives after many higher-numbered packets have been received. An endpoint -SHOULD use a large enough packet number encoding to allow the packet number to -be recovered even if the packet arrives after packets that are sent afterwards. - -Prior to any acknowledgements being received for a packet number space, there is -no largest acknowledge packet, so the full packet number is encoded in the -header. +Prior to receiving an acknowledgement for a packet number space, the full packet +number MUST be included. + +After an acknowledgement is received for a packet number space, the sender MUST +use a packet number size able to represent more than twice as large a range than +the difference between the largest acknowledged packet and packet number being +sent. A peer receiving the packet will then correctly decode the packet number, +unless the packet is delayed in transit such that it arrives after many +higher-numbered packets have been received. An endpoint SHOULD use a large enough +packet number encoding to allow the packet number to be recovered even if the +packet arrives after packets that are sent afterwards. As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous unacknowledged packet From e25d48bd6227bf2f0616da85f317c341441977ad Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Mon, 20 Jul 2020 20:06:33 -0700 Subject: [PATCH 4/4] fix lint --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a65cc27c80..ab9212fcb9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -4251,9 +4251,9 @@ use a packet number size able to represent more than twice as large a range than the difference between the largest acknowledged packet and packet number being sent. A peer receiving the packet will then correctly decode the packet number, unless the packet is delayed in transit such that it arrives after many -higher-numbered packets have been received. An endpoint SHOULD use a large enough -packet number encoding to allow the packet number to be recovered even if the -packet arrives after packets that are sent afterwards. +higher-numbered packets have been received. An endpoint SHOULD use a large +enough packet number encoding to allow the packet number to be recovered even +if the packet arrives after packets that are sent afterwards. As a result, the size of the packet number encoding is at least one bit more than the base-2 logarithm of the number of contiguous unacknowledged packet