From ec7c839c4b8e96d23fe474cb42451f23af226cb2 Mon Sep 17 00:00:00 2001 From: Martin Duke Date: Wed, 23 Oct 2019 15:19:27 -0700 Subject: [PATCH] Delete reference to crypto timeout --- draft-ietf-quic-transport.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 9e09b89050..58ac5957c2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1605,11 +1605,11 @@ the amplification restriction. Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached. In order to avoid this causing a -handshake deadlock, clients SHOULD send a packet upon a crypto retransmission -timeout, as described in {{QUIC-RECOVERY}}. If the client has no data to -retransmit and does not have Handshake keys, it SHOULD send an Initial packet in -a UDP datagram of at least 1200 bytes. If the client has Handshake keys, it -SHOULD send a Handshake packet. +handshake deadlock, clients SHOULD send a packet upon a probe timeout, as +described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does +not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of +at least 1200 bytes. If the client has Handshake keys, it SHOULD send a +Handshake packet. A server might wish to validate the client address before starting the cryptographic handshake. QUIC uses a token in the Initial packet to provide