From 295e0c9afc7eb80454f3fd0bd9d64d4879f85573 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 23 Sep 2019 10:57:53 -0400 Subject: [PATCH 1/7] MUST send new data or retransmit data if possible Fixes #3056 --- draft-ietf-quic-recovery.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index a90cad46ad..9eab23d670 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -526,12 +526,11 @@ as a probe, unless there is no data available to send. An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. -It is possible that the sender has no new or previously-sent data to send. As -an example, consider the following sequence of events: new application data is -sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and -then the original transmission is acknowledged. In the absence of any new -application data, a PTO timer expiration now would find the sender with no new -or previously-sent data to send. +When the PTO timer expires, and there is new or previously sent data, it MUST +be sent. It is possible the sender has no new or previously-sent data to send. +As an example, consider the following sequence of events: new application data +is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, +and then the original transmission is acknowledged. When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. From 409286b111330780882fe2ae17bbe405d9f25b09 Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 23 Sep 2019 11:26:45 -0400 Subject: [PATCH 2/7] Update draft-ietf-quic-recovery.md Move the section on what encryption level to send first down. --- draft-ietf-quic-recovery.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 9eab23d670..0de2f30b1b 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -496,10 +496,8 @@ be considered an RTT sample. Until the server has validated the client's address on the path, the amount of data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. -Data at Initial encryption MUST be retransmitted before Handshake data and -data at Handshake encryption MUST be retransmitted before any ApplicationData -data. If no data can be sent, then the PTO alarm MUST NOT be armed until -data has been received from the client. +If no data can be sent, then the PTO alarm MUST NOT be armed until data has +been received from the client. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server @@ -527,13 +525,15 @@ to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. When the PTO timer expires, and there is new or previously sent data, it MUST -be sent. It is possible the sender has no new or previously-sent data to send. +be sent. Data at Initial encryption MUST be sent before Handshake data and +data at Handshake encryption MUST be sent before any ApplicationData data. + +It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new application data is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, -and then the original transmission is acknowledged. - -When there is no data to send, the sender SHOULD send a PING or other -ack-eliciting frame in a single packet, re-arming the PTO timer. +and then the original transmission is acknowledged. When there is no data to +send, the sender SHOULD send a PING or other ack-eliciting frame in a single +packet, re-arming the PTO timer. Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark any packets still in flight as lost. Doing so avoids sending an additional From df8c4feb8412cdc5060f427eb3e64672db56e0db Mon Sep 17 00:00:00 2001 From: ianswett Date: Mon, 23 Sep 2019 22:11:31 -0400 Subject: [PATCH 3/7] unacknowledged data --- draft-ietf-quic-recovery.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 0de2f30b1b..7b02587d31 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -524,9 +524,10 @@ as a probe, unless there is no data available to send. An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. -When the PTO timer expires, and there is new or previously sent data, it MUST -be sent. Data at Initial encryption MUST be sent before Handshake data and -data at Handshake encryption MUST be sent before any ApplicationData data. +When the PTO timer expires, and there is new or previously sent unacknowledged +data, it MUST be sent. Data at Initial encryption MUST be sent before +Handshake data and data at Handshake encryption MUST be sent before any +ApplicationData data. It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new application data From 0236874f3a51eb4166b9070a21f1acd8dae432b1 Mon Sep 17 00:00:00 2001 From: ianswett Date: Tue, 24 Sep 2019 14:34:29 -0400 Subject: [PATCH 4/7] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 7b02587d31..35cee41a68 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -495,9 +495,9 @@ a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT be considered an RTT sample. Until the server has validated the client's address on the path, the amount of -data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}. -If no data can be sent, then the PTO alarm MUST NOT be armed until data has -been received from the client. +data it can send is limited to three times the amount of data received, +as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent, +then the PTO alarm MUST NOT be armed. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server From 3662405decdc750cb97d7b1bd3eab1ad62abc0ff Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 24 Oct 2019 17:52:20 -0400 Subject: [PATCH 5/7] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 35cee41a68..89796e7bc5 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -525,7 +525,7 @@ to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. When the PTO timer expires, and there is new or previously sent unacknowledged -data, it MUST be sent. Data at Initial encryption MUST be sent before +data, it MUST be sent. Data that was previously sent with Initial encryption MUST be sent before Handshake data and data at Handshake encryption MUST be sent before any ApplicationData data. From 6a225b8bfc8b8aad98fa0ffee512f59940db48b5 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 24 Oct 2019 17:52:41 -0400 Subject: [PATCH 6/7] Update draft-ietf-quic-recovery.md Co-Authored-By: Jana Iyengar --- draft-ietf-quic-recovery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 89796e7bc5..5e3ed0b193 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -526,7 +526,7 @@ expensive consecutive PTO expiration due to a single lost datagram. When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent. Data that was previously sent with Initial encryption MUST be sent before -Handshake data and data at Handshake encryption MUST be sent before any +Handshake data and, similarly, data previously sent at Handshake encryption MUST be sent before any ApplicationData data. It is possible the sender has no new or previously-sent data to send. From 886db2af9e5c70a553dcf1d71d34fbe75c963a2d Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 24 Oct 2019 17:53:34 -0400 Subject: [PATCH 7/7] Update draft-ietf-quic-recovery.md --- draft-ietf-quic-recovery.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 5e3ed0b193..8dc44badbb 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -525,9 +525,9 @@ to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. When the PTO timer expires, and there is new or previously sent unacknowledged -data, it MUST be sent. Data that was previously sent with Initial encryption MUST be sent before -Handshake data and, similarly, data previously sent at Handshake encryption MUST be sent before any -ApplicationData data. +data, it MUST be sent. Data that was previously sent with Initial encryption +MUST be sent before Handshake data and data previously sent at Handshake +encryption MUST be sent before any ApplicationData data. It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new application data