From 8de90213184a323618a32502904f37673640ca5d Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 22 Jan 2020 17:39:10 +0100 Subject: [PATCH 1/4] editorial: This sentence was hard to parse for me (recovery) So here is an alternative proposal. However I also wonder why this paragraph is a MUST requirement while the previous statement (avoiding multiple samples of the same packet) is only a SHOULD? I would see it rather the other way around or both MUSTs. --- 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 ca1d9c309a..858922516b 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -272,9 +272,10 @@ SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the largest acknowledged packet. An RTT sample MUST NOT be generated on receiving an ACK frame that does not -newly acknowledge at least one ack-eliciting packet. A peer does not send an -ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is -subsequently sent can include an arbitrarily large Ack Delay field. Ignoring +newly acknowledge at least one ack-eliciting packet. A peer does usally not +send an ACK frame when only non-ack-eliciting packets are received. Therefore +an ACK frame that contains only acknowledge for non-ack-eliciting packets is +can subsequently include an arbitrarily large Ack Delay value. Ignoring such ACK frames avoids complications in subsequent smoothed_rtt and rttvar computations. From d3cc03174ba5f0a7d7bbcc451d08c920a0fdf9d1 Mon Sep 17 00:00:00 2001 From: mirjak Date: Wed, 22 Jan 2020 23:16:35 +0100 Subject: [PATCH 2/4] English hard be... --- draft-ietf-quic-recovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 858922516b..7295598bb9 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -272,9 +272,9 @@ SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the largest acknowledged packet. An RTT sample MUST NOT be generated on receiving an ACK frame that does not -newly acknowledge at least one ack-eliciting packet. A peer does usally not +newly acknowledge at least one ack-eliciting packet. A peer usually does not send an ACK frame when only non-ack-eliciting packets are received. Therefore -an ACK frame that contains only acknowledge for non-ack-eliciting packets is +an ACK frame that only contains acknowledgements for non-ack-eliciting packets can subsequently include an arbitrarily large Ack Delay value. Ignoring such ACK frames avoids complications in subsequent smoothed_rtt and rttvar computations. From f8162becbde33a2e11f43f303b511c3dad949ade Mon Sep 17 00:00:00 2001 From: mirjak Date: Thu, 23 Jan 2020 10:23:58 +0100 Subject: [PATCH 3/4] Update draft-ietf-quic-recovery.md Co-Authored-By: Martin Thomson --- 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 7295598bb9..a6729e59a5 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -275,7 +275,7 @@ An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet. A peer usually does not send an ACK frame when only non-ack-eliciting packets are received. Therefore an ACK frame that only contains acknowledgements for non-ack-eliciting packets -can subsequently include an arbitrarily large Ack Delay value. Ignoring +could include an arbitrarily large Ack Delay value. Ignoring such ACK frames avoids complications in subsequent smoothed_rtt and rttvar computations. From 81f10dc8a143f6da754daab8690256c0597a6d07 Mon Sep 17 00:00:00 2001 From: mirjak Date: Thu, 23 Jan 2020 10:24:19 +0100 Subject: [PATCH 4/4] 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 a6729e59a5..5fbed8476e 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -274,7 +274,7 @@ largest acknowledged packet. An RTT sample MUST NOT be generated on receiving an ACK frame that does not newly acknowledge at least one ack-eliciting packet. A peer usually does not send an ACK frame when only non-ack-eliciting packets are received. Therefore -an ACK frame that only contains acknowledgements for non-ack-eliciting packets +an ACK frame that contains acknowledgements for only non-ack-eliciting packets could include an arbitrarily large Ack Delay value. Ignoring such ACK frames avoids complications in subsequent smoothed_rtt and rttvar computations.