From 7f887a92f9a235c7bfc3d89644ef1d241dfc88db Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 23 Apr 2020 16:08:35 -0400 Subject: [PATCH 1/2] The peer only has 1 key, so send both Sending in multiple PN spaces on PTO is particularly useful when the peer only has receive keys for 1 pn space, and the you don't know which. Fixes #3583 --- draft-ietf-quic-recovery.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 1f5f5f38f2..0235ac538a 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -597,7 +597,11 @@ All probe packets sent on a PTO MUST be ack-eliciting. In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet -number spaces with in-flight data, coalescing packets if possible. +number spaces with in-flight data, coalescing packets if possible. This is +particularly valuable when the server has both Initial and Handshake data +in flight or the client has both Handshake and ApplicationData in flight, +because in both casess the peer only has receive keys for one of the two +packet number spaces. If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay. From f4408896e46b394fd4a9b99824ef8f3a52b23ca3 Mon Sep 17 00:00:00 2001 From: ianswett Date: Thu, 23 Apr 2020 17:22:08 -0400 Subject: [PATCH 2/2] 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 0235ac538a..9f6cad8e19 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -599,9 +599,9 @@ In addition to sending data in the packet number space for which the timer expired, the sender SHOULD send ack-eliciting packets from other packet number spaces with in-flight data, coalescing packets if possible. This is particularly valuable when the server has both Initial and Handshake data -in flight or the client has both Handshake and ApplicationData in flight, -because in both casess the peer only has receive keys for one of the two -packet number spaces. +in-flight or the client has both Handshake and ApplicationData in-flight, +because the peer might only have receive keys for one of the two packet number +spaces. If the sender wants to elicit a faster acknowledgement on PTO, it can skip a packet number to eliminate the ack delay.