Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.

a few suggestions

> @@ -1626,14 +1626,17 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by 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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more

```suggestion
acknowledgements for all the data it has sent, it has no reason to send more
```

> @@ -1626,14 +1626,17 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by 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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server

```suggestion
the client does not send additional Initial or Handshake packets. This can happen because the server
```

> @@ -1626,14 +1626,17 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by 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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received

```suggestion
can reach its anti-amplification limit, and if the client has received
```

> @@ -1626,14 +1626,17 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by 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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not

```suggestion
additional packets, the server will be unable to send more data because it has not
```

> @@ -1626,14 +1626,17 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by 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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not
+received enough from the client or validated the clients address. To prevent

```suggestion
received enough data from the client or has not validated the client's address. To prevent
```

> -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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not
+received enough from the client or validated the clients address. To prevent
+this deadlock, clients MUST send a packet on a probe timeout, or PTO;

```suggestion
this deadlock, clients MUST send a packet on a probe timeout (PTO, 
```

> -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 MUST 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 MUST 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.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not
+received enough from the client or validated the clients address. To prevent
+this deadlock, clients MUST send a packet on a probe timeout, or PTO;
+see Section 5.3 of {{QUIC-RECOVERY}}. In this case, the client MUST send an

```suggestion
see Section 5.3 of {{QUIC-RECOVERY}}). Specifically, the client MUST send an
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445#pullrequestreview-364527056