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

From: ianswett <[email-masked]>
Date: Sun, 09 Feb 2020 11:44:06 -0800

Clarifies why a client might send a Handshake packet, as well as improving the surrounding anti-deadlock text.

Fixes #2598
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3445

-- Commit Summary --

  * Clarify client anti-amplification response

-- File Changes --

    M draft-ietf-quic-transport.md (14)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3445.patch
https://github.com/quicwg/base-drafts/pull/3445.diff

-- 
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

---

From: ianswett <[email-masked]>
Date: Sun, 09 Feb 2020 11:45:49 -0800

@ianswett pushed 1 commit.

6138a07267ab9a28d00eaec8f3699cf60a6dc7fe  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/8c52fd83cb5a0228dd696e45f556617e8156036f..6138a07267ab9a28d00eaec8f3699cf60a6dc7fe

---

From: ianswett <[email-masked]>
Date: Sun, 09 Feb 2020 11:50:48 -0800

2793b5c477c8ef4672c5d056510d685f83b0bf90  Simplify

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/6138a07267ab9a28d00eaec8f3699cf60a6dc7fe..2793b5c477c8ef4672c5d056510d685f83b0bf90

---

From: ianswett <[email-masked]>
Date: Sun, 09 Feb 2020 11:52:43 -0800

a6e821584e80f2fa5efe02a21aba0926131d7a4d  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/2793b5c477c8ef4672c5d056510d685f83b0bf90..a6e821584e80f2fa5efe02a21aba0926131d7a4d

---

From: Martin Thomson <[email-masked]>
Date: Sun, 09 Feb 2020 15:01:44 -0800

martinthomson commented on this pull request.

> @@ -1626,14 +1626,14 @@ 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 situation in
+which the server cannot send due to the anti-amplification limit
+and the client has no data to send because client Initial data has been
+acknowledged and it does not yet have Handshake data to send. In order to avoid

This long compound sentence probably needs to be split up.

> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial packets.  The server can reaches its anti-amplification limit (see {{xxx}}), but the client has received and acknowledged Initial packets without having a need to send a Handshake packet.  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.  To prevent this deadlock, clients MUST send a packet on a probe timeout, or PTO; see Section XX of {{QUIC-RECOVERY}}.  If [...]

-- 
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-355641304

---

From: ianswett <[email-masked]>
Date: Mon, 10 Feb 2020 09:49:26 -0800

321c59afbcf01afa80373633c9ec2058a9088cf8  Reworked Martin's suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/a6e821584e80f2fa5efe02a21aba0926131d7a4d..321c59afbcf01afa80373633c9ec2058a9088cf8

---

From: ianswett <[email-masked]>
Date: Mon, 10 Feb 2020 09:50:03 -0800

ianswett commented on this pull request.

Thanks, I tried to rewrite based on your suggestion.  Tell me what you think.

-- 
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#discussion_r377218857

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Feb 2020 11:20:32 -0800

Thanks. Struggling a little with that second sentence though. 

> @@ -1626,13 +1626,16 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 
-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
+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 the clients Initial data has been

This is missing an apostrophe on Clients. But more seriously, it looks like a sentence fragment. 

Maybe move the part about the client not sending up into this sentence. 

> The server can reach its anti-amplification limit, but the client has no reason to send more packets as all the data it has sent has been acknowledged.

-- 
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-356196403

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 09:44:14 -0800

86ae5b47c6f73a1356b211cf4db0a6b2dcd23d85  Martin's suggestion reworded

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/321c59afbcf01afa80373633c9ec2058a9088cf8..86ae5b47c6f73a1356b211cf4db0a6b2dcd23d85

---

From: ianswett <[email-masked]>
Date: Sat, 15 Feb 2020 09:45:06 -0800

Thanks for the suggestion, I took it and then tweaked it.  PTAL.

-- 
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#discussion_r379845294

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Feb 2020 15:41:32 -0800

martinthomson approved this pull request.

-- 
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-359439533

---

From: Christian Huitema <[email-masked]>
Date: Tue, 18 Feb 2020 08:56:07 -0800

huitema approved this pull request.

This text addresses the concerns in issue #3395, and would remove the need for PR #3416. I like it. I am just a tiny bit concerned with the implications of sending a Ping that would force an Initial or Handshake response.

-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
+Initial packet in a UDP datagram of at least 1200 bytes if it does not have
+Handshake keys, and otherwise send a Handshake packet.

Yes. The next question is, what content shall the client place in the Initial or Handshake packet? Just PAD? Ping and PAD?

-- 
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-360504881

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Feb 2020 18:01:09 -0800

It seems to me that this doesn't matter.  Probing generally goes for ack-eliciting, and some might favour sending data over just a PING, but if the server only needs more bytes, it shouldn't matter if this is PADDING, PING, or CRYPTO. 

-- 
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#discussion_r381039296

---

From: Christian Huitema <[email-masked]>
Date: Tue, 18 Feb 2020 18:48:19 -0800

huitema commented on this pull request.

I would favor pure pad, personally, so as to not require its own ack, retransmit, etc. Also, sending it with the proper DCID will get the server out of the DOD amplification control mode.

-- 
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#discussion_r381050679

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Feb 2020 13:22:03 -0800

A proper, updated DCID isn't guaranteed to unblock the server. That is why we haven't expressly allowed for that to be used.

-- 
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#discussion_r381551611

---

From: Christian Huitema <[email-masked]>
Date: Wed, 19 Feb 2020 16:27:42 -0800

I am not asking for a change in the current text. This PR is fine.

-- 
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#discussion_r381625040

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 25 Feb 2020 15:37:44 -0800

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

```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

```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

```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

```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

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

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

```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

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:23:42 -0800

55d617658fd32b95c54f27e75d1bab5739032537  Jana's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/86ae5b47c6f73a1356b211cf4db0a6b2dcd23d85..55d617658fd32b95c54f27e75d1bab5739032537

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:25:24 -0800

9124ab1f5e462d386eec478e3813cfccec00148a  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/55d617658fd32b95c54f27e75d1bab5739032537..9124ab1f5e462d386eec478e3813cfccec00148a

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:27:20 -0800

0ce17f386f32e69c5e1abeaaddaccc273e4e110c  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/9124ab1f5e462d386eec478e3813cfccec00148a..0ce17f386f32e69c5e1abeaaddaccc273e4e110c

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:29:23 -0800

52649b9ecb3d4ddf3325e5db8891e7a2e6d95813  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/0ce17f386f32e69c5e1abeaaddaccc273e4e110c..52649b9ecb3d4ddf3325e5db8891e7a2e6d95813

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:35:24 -0800

1bc588fe9dc0227b2aeda8a6311f22ea7c2157a2  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/52649b9ecb3d4ddf3325e5db8891e7a2e6d95813..1bc588fe9dc0227b2aeda8a6311f22ea7c2157a2

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 17:36:16 -0800

1a952f91d3f8d371e5fadfb2a56fb8c63ff6d5de  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/1bc588fe9dc0227b2aeda8a6311f22ea7c2157a2..1a952f91d3f8d371e5fadfb2a56fb8c63ff6d5de

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 18:03:48 -0800

1e60a825e535c3d1fddff7c3121b60a9bae1db40  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/1a952f91d3f8d371e5fadfb2a56fb8c63ff6d5de..1e60a825e535c3d1fddff7c3121b60a9bae1db40

---

From: ianswett <[email-masked]>
Date: Wed, 26 Feb 2020 18:05:40 -0800

b19b38b5fcb9e4c24fbdf95328fa7f6c726a5180  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3445/files/1e60a825e535c3d1fddff7c3121b60a9bae1db40..b19b38b5fcb9e4c24fbdf95328fa7f6c726a5180

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Feb 2020 19:09:04 -0800

Merged #3445 into master.

-- 
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#event-3076221887