From c04a11e96ccc0959fd1eaf1074e34cda84d02002 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Sun, 21 Jul 2019 09:50:17 -0400 Subject: [PATCH] Move to Handshake section --- draft-ietf-quic-recovery.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-recovery.md b/draft-ietf-quic-recovery.md index 07aaa63623..894132e674 100644 --- a/draft-ietf-quic-recovery.md +++ b/draft-ietf-quic-recovery.md @@ -589,6 +589,14 @@ necessary, to allow the server to continue sending data. If Handshake keys are available to the client, it MUST send a Handshake packet, and otherwise it MUST send an Initial packet in a UDP datagram of at least 1200 bytes. +If the handshake is complete, but not confirmed (see Section 4.1.1 and Section +4.1.2 of {{QUIC-TLS}}), in addition to sending unacknowledged CRYPTO data in a +probe packet, endpoints SHOULD send an ack-eliciting 1-RTT packet. This can be +coalesced with Handshake packets, even if there is sufficient unacknowledged +CRYPTO data outstanding to consume the entire PMTU. Sending an ack-eliciting +1-RTT packet provides a peer with the opportunity to confirm the handshake and +allow all state associated with Handshake packets to be discarded. + Because Initial packets containing only PADDING do not elicit an acknowledgement, they may never be acknowledged, but they are removed from bytes in flight when the client gets Handshake keys and the Initial keys are @@ -629,14 +637,6 @@ MAY use alternate strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. -If the handshake is complete, but not confirmed (see Section 4.1.1 and Section -4.1.2 of {{QUIC-TLS}}), in addition to sending unacknowledged CRYPTO data, -endpoints SHOULD send an ack-eliciting 1-RTT packet. This can be coalesced with -Handshake packets, even if there is sufficient unacknowledged CRYPTO data -outstanding to consume the entire PMTU. Sending an ack-eliciting 1-RTT packet -provides a peer with the opportunity to confirm the handshake and allow all -state associated with Handshake packets to be discarded. - When the PTO timer expires multiple times and new data cannot be sent, implementations must choose between sending the same payload every time or sending different payloads. Sending the same payload may be simpler