Subject: [quicwg/base-drafts] Clarify ACK of ACKs and bundling a PING (#2794)

From: ianswett <[email-masked]>
Date: Fri, 14 Jun 2019 19:07:50 -0700

Fixes #2546 

If there's anything else discussed in London that I missed, please tell me.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Clarify ACK of ACKs and bundling a PING

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2794.patch
https://github.com/quicwg/base-drafts/pull/2794.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/2794

---

From: ianswett <[email-masked]>
Date: Fri, 14 Jun 2019 19:08:50 -0700

@ianswett pushed 1 commit.

8031f58dee2bd4aa29375d402bc64d9c6cb584ac  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/2794/files/99ced9ef1199ad0efb5eb906171e994fda6826fd..8031f58dee2bd4aa29375d402bc64d9c6cb584ac

---

From: Marten Seemann <[email-masked]>
Date: Fri, 14 Jun 2019 19:21:37 -0700

marten-seemann 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/2794#pullrequestreview-250174441

---

From: MikkelFJ <[email-masked]>
Date: Sat, 15 Jun 2019 01:40:08 -0700

Isn't this just moving up one level in the inception layer?
Now you must not send ACK+PING too often to prevent an indefinite feedback loop?

Why not just say that an ACK should not ACK / PAD only frames for more than a fraction of the packets to avoid feedback loops and to ensure eventual reduction of gap accounting?

-- 
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/2794#issuecomment-502347284

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 07:53:50 -0700

c9da070a4f4301456ad88d591dc3c9d5e7a2589d  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/2794/files/8031f58dee2bd4aa29375d402bc64d9c6cb584ac..c9da070a4f4301456ad88d591dc3c9d5e7a2589d

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 08:21:24 -0700

@mikkelfj My past experience has been that it's better if the sender of ACKs is in control of how often they want an ACK in response.  There are a number of packet tracking/ACKing algorithms which never require ACKs of ACK-only packets, and I think we should accommodate those.

Making the receiver of ACKs guess how often to ACK ACKs is a problem that's impossible to get right, and as @janaiyengar said on the issue, one can never rely on any receiver behavior regarding when they'll ACK ACKs, so it's more robust if the sender is in control.

I will add normative text about not including a PING with every ACK.

-- 
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/2794#issuecomment-502728738

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Jun 2019 10:03:42 -0700

OK, that makes sense.

-- 
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/2794#issuecomment-502768471

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Jun 2019 10:25:57 -0700

mikkelfj commented on this pull request.

>  Because ACK frames are not sent in response to ACK-only packets, a receiver that
 is only sending ACK frames will only receive acknowledgements for its packets if
 the sender includes them in packets with non-ACK frames.  A sender SHOULD bundle
 ACK frames with other frames when possible.
 
+To limit ACK Ranges (see {{ack-ranges}}) to those that have not yet been
+received by the sender, the receiver SHOULD track which ACK frames have been
+acknowledged by its peer. The receiver SHOULD exclude already acknowledged
+packets from future ACK frames whenever these packets would unnecessarily
+contribute to the ACK frame size.  When the receiver is only sending ACK-only
+packets, it can bundle a PING with a fraction of them, such as one per round
+trip, to drop unnecessary ACK ranges and any tracking state associated with the
+previously sent ACK-only packets.  The receiver MUST NOT bundle a PING with all
+packets that would otherwise be ACK-only, in order to avoid an indefinite

```suggestion
packets that would otherwise not be ACK-eliciting, in order to avoid an indefinite
```
PADDING+PING

-- 
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/2794#pullrequestreview-250633910

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:41:54 -0700

e246745e8d3e4354a2b0cc6b3b3ee2bb489a85ff  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/2794/files/c9da070a4f4301456ad88d591dc3c9d5e7a2589d..e246745e8d3e4354a2b0cc6b3b3ee2bb489a85ff

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:44:43 -0700

58e174a6c6afa7e8d24e615545b269faf0d50231  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/2794/files/e246745e8d3e4354a2b0cc6b3b3ee2bb489a85ff..58e174a6c6afa7e8d24e615545b269faf0d50231

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:46:48 -0700

33aa341ce7a3f2966bb22c08971d91ed55bf9da0  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/2794/files/58e174a6c6afa7e8d24e615545b269faf0d50231..33aa341ce7a3f2966bb22c08971d91ed55bf9da0

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:48:11 -0700

aa377d4eb35e0e6908ed21b18dce6608df8aead3  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/2794/files/33aa341ce7a3f2966bb22c08971d91ed55bf9da0..aa377d4eb35e0e6908ed21b18dce6608df8aead3

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:51:03 -0700

I've now removed ACK-only from the transport text, and replaced it with ACK-eliciting.

-- 
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/2794#issuecomment-502913537

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 18:53:05 -0700

77b46c30d60fb46e971d302c9324d377de1bdb8e  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/2794/files/aa377d4eb35e0e6908ed21b18dce6608df8aead3..77b46c30d60fb46e971d302c9324d377de1bdb8e

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 19:27:04 -0700

2b4486f2c49c84726bd0f8f082ff696d7b73ddbd  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/2794/files/77b46c30d60fb46e971d302c9324d377de1bdb8e..2b4486f2c49c84726bd0f8f082ff696d7b73ddbd

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 19:31:14 -0700

8a4593370beb26f67b4fa687fb9fe7fe38b0e56a  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/2794/files/2b4486f2c49c84726bd0f8f082ff696d7b73ddbd..8a4593370beb26f67b4fa687fb9fe7fe38b0e56a

---

From: ianswett <[email-masked]>
Date: Mon, 17 Jun 2019 19:37:17 -0700

2c3addf78ae448fd6593c3b384aa83959871bab5  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/2794/files/8a4593370beb26f67b4fa687fb9fe7fe38b0e56a..2c3addf78ae448fd6593c3b384aa83959871bab5

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Jun 2019 22:55:05 -0700

> @@ -2883,16 +2884,21 @@ needing acknowledgement are received.  The sender can use the receiver's
 Strategies and implications of the frequency of generating acknowledgments are
 discussed in more detail in {{QUIC-RECOVERY}}.
 
+ACK-only packets are only sent in response to ACK-eliciting packets, so a
+receiver that is only sending ACK frames will only receive acknowledgements
+for its packets if the sender includes them in packets with non-ACK frames.

```suggestion
for its packets if the sender includes them in packets with ACK-eliciting frames.
```
cover PADDING-only (as pointless as it might seem).

-- 
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/2794#pullrequestreview-250871980

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 07:26:13 -0700

045f99415dfce3e2b1607d16193d9186f68abc5f  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/2794/files/2c3addf78ae448fd6593c3b384aa83959871bab5..045f99415dfce3e2b1607d16193d9186f68abc5f

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 07:26:44 -0700

ianswett commented on this pull request.

This section is the only use of ACK-eliciting, so I define it at the beginning of the section now.

-- 
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/2794#discussion_r294851999

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 14:03:06 -0700

f2b2ebb1f721907b233059b7caeca4ecae03f0a8  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/2794/files/045f99415dfce3e2b1607d16193d9186f68abc5f..f2b2ebb1f721907b233059b7caeca4ecae03f0a8

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2019 15:28:42 -0700

martinthomson approved this pull request.

>  To limit ACK Ranges (see {{ack-ranges}}) to those that have not yet been
 received by the sender, the receiver SHOULD track which ACK frames have been
 acknowledged by its peer. The receiver SHOULD exclude already acknowledged
 packets from future ACK frames whenever these packets would unnecessarily
-contribute to the ACK frame size.
-
-Because ACK frames are not sent in response to ACK-only packets, a receiver that
-is only sending ACK frames will only receive acknowledgements for its packets if
-the sender includes them in packets with non-ACK frames.  A sender SHOULD bundle
-ACK frames with other frames when possible.
+contribute to the ACK frame size.  When the receiver is only sending non
+ACK-eliciting packets, it can bundle a PING with a fraction of them, such as one

non-ACK-eliciting?

+ACK-only packets are only sent in response to ACK-eliciting packets, so a
+receiver that is only sending ACK frames will only receive acknowledgements
+for its packets if the sender includes them in packets with ACK-eliciting

An endpoint that is only sending ACK frames won't receive acknowledgments from its peer unless those acknowledgements are included in packets [...] 

-- 
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/2794#pullrequestreview-251394349

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:36:51 -0700

5eaf4d9582c65c7d618e7b90cfce51243effaf02  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/2794/files/f2b2ebb1f721907b233059b7caeca4ecae03f0a8..5eaf4d9582c65c7d618e7b90cfce51243effaf02

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:37:43 -0700

bf9e38c8feb47740f2615c32e8000b81cafa53fb  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/2794/files/5eaf4d9582c65c7d618e7b90cfce51243effaf02..bf9e38c8feb47740f2615c32e8000b81cafa53fb

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:38:16 -0700

Done.

-- 
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/2794#discussion_r295057493

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:39:40 -0700

111407d94ec4cadafa75ebffd1a3a9f3b94b82d0  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/2794/files/bf9e38c8feb47740f2615c32e8000b81cafa53fb..111407d94ec4cadafa75ebffd1a3a9f3b94b82d0

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2019 15:46:46 -0700

martinthomson commented on this pull request.

 received by the sender, the receiver SHOULD track which ACK frames have been
 acknowledged by its peer. The receiver SHOULD exclude already acknowledged
 packets from future ACK frames whenever these packets would unnecessarily
-contribute to the ACK frame size.
-
-Because ACK frames are not sent in response to ACK-only packets, a receiver that
-is only sending ACK frames will only receive acknowledgements for its packets if
-the sender includes them in packets with non-ACK frames.  A sender SHOULD bundle
-ACK frames with other frames when possible.
+contribute to the ACK frame size.  When the receiver is only sending
+non-ACK-eliciting packets, it can bundle a PING with a fraction of them, such
+as one per round trip, to enable dropping unnecessary ACK ranges and any state
+for previously sent packets.  The receiver MUST NOT bundle a PING with all
+packets that would otherwise not be ACK-eliciting, in order to avoid an
+indefinite feedback loop of ACKs.

```suggestion
indefinite feedback loop of acknowledgements.
```

-- 
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/2794#pullrequestreview-251399992

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:53:14 -0700

92716d077e40dd49870aa9c39bcaca9d80e5d7c8  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/2794/files/111407d94ec4cadafa75ebffd1a3a9f3b94b82d0..92716d077e40dd49870aa9c39bcaca9d80e5d7c8

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 15:56:08 -0700

675a2ed31f8f3ef64f47f0aba973ce20c227e174  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/2794/files/92716d077e40dd49870aa9c39bcaca9d80e5d7c8..675a2ed31f8f3ef64f47f0aba973ce20c227e174

---

From: MikkelFJ <[email-masked]>
Date: Tue, 18 Jun 2019 16:06:20 -0700

> @@ -2884,10 +2884,10 @@ needing acknowledgement are received.  The sender can use the receiver's
 
-ACK-only packets are only sent in response to ACK-eliciting packets, so a
-receiver that is only sending ACK frames will only receive acknowledgements
-for its packets if the sender includes them in packets with ACK-eliciting
-frames.  A sender SHOULD bundle ACK frames with other frames when possible.
+An endpoint that is only sending ACK frames won't receive acknowledgments from

won't -> will not

-- 
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/2794#pullrequestreview-251405506

---

From: ianswett <[email-masked]>
Date: Tue, 18 Jun 2019 16:55:53 -0700

7ed03b155612dbf05f75e415c8ac804887f5832a  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/2794/files/675a2ed31f8f3ef64f47f0aba973ce20c227e174..7ed03b155612dbf05f75e415c8ac804887f5832a

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Jun 2019 21:40:45 -0700

kazuho approved this pull request.

LGTM, though I have very nit-picky comments.

> @@ -2860,12 +2860,13 @@ valid frames? -->
 ### Sending ACK Frames
 
 An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+received non-ACK-eliciting packet(ie: one containing only ACK and/or PADDING

Maybe "MUST NOT send more than one non-ACK-eliciting packet in response to one non-ACK-eliciting packet"?

The packet the endpoint sends can also be a combination of ACK and PADDING.

> @@ -2860,12 +2860,13 @@ valid frames? -->
 ### Sending ACK Frames
 
 An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+received non-ACK-eliciting packet(ie: one containing only ACK and/or PADDING
+frames).  An endpoint MUST NOT send a packet containing only an ACK frame in

Here also.

+An endpoint that is only sending ACK frames will not receive acknowledgments

Maybe s/only sending ACK frames/only sending acknowledgements/.

-- 
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/2794#pullrequestreview-251470349

---

From: MikkelFJ <[email-masked]>
Date: Tue, 18 Jun 2019 22:57:32 -0700

### Sending ACK Frames

This could get messy with timeouts and retransmissions. You may want to ensure that peer has ACK but there might not be space in a packet being retransmitted.

-- 
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/2794#discussion_r295131217

---

From: ianswett <[email-masked]>
Date: Wed, 19 Jun 2019 14:17:13 -0700

### Sending ACK Frames

This text is actually backwards, fixing it to remove the non

-- 
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/2794#discussion_r295527730

---

From: ianswett <[email-masked]>
Date: Wed, 19 Jun 2019 14:21:59 -0700

Done

-- 
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/2794#discussion_r295529515

---

From: ianswett <[email-masked]>
Date: Wed, 19 Jun 2019 14:22:54 -0700

416583a40e672626baedc746e5a5e6f94fd4979c  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/2794/files/7ed03b155612dbf05f75e415c8ac804887f5832a..416583a40e672626baedc746e5a5e6f94fd4979c

---

From: ianswett <[email-masked]>
Date: Fri, 21 Jun 2019 10:42:30 -0700

9a2e34d2d6be4d7e04bf1175e50791cda6c8a26e  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/2794/files/416583a40e672626baedc746e5a5e6f94fd4979c..9a2e34d2d6be4d7e04bf1175e50791cda6c8a26e

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 23 Jun 2019 21:31:37 -0700

kazuho commented on this pull request.

 ### Sending ACK Frames

FWIW, the point of my previous comment https://github.com/quicwg/base-drafts/pull/2794#discussion_r295118147 was that "MUST NOT send more than one packet containing only an ACK frame" does not prohibit one from sending a packet that contains ACK and PADDING.

This is admittedly a nit-pick, but discussing ACK-only on the send side while discussing ACK+PADDING on the receive side is confusing.

Hence the suggestion to change the text to "MUST NOT send more than one non-ACK-eliciting packet per ..."

 ### Sending ACK Frames
 
 An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+received ACK-eliciting packet(one containing frames other than ACK and/or
+PADDING).  An endpoint MUST NOT send a packet containing only an ACK frame in

s/MUST NOT send a packet containing only an ACK frame/MUST NOT send a non-ack-eliciting packet/.

-- 
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/2794#pullrequestreview-253195589

---

From: MikkelFJ <[email-masked]>
Date: Mon, 24 Jun 2019 00:09:36 -0700

### Sending ACK Frames

yeah I thought of that one - but didn't say anything because you are discussing send ACK's. But to correct yes, it needs to include 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/2794#discussion_r296577668

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 07:23:42 -0700

### Sending ACK Frames

I'm not sure that change is correct.  ACK only packets don't count towards congestion control, so they're somewhat special.  I'd be curious to have @janaiyengar opinion on this.

-- 
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/2794#discussion_r296748972

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 09:31:30 -0700

36a2d9476358acf4c8b38dd9529b0429084638c7  Add intro sentence about ACK only packets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2794/files/9a2e34d2d6be4d7e04bf1175e50791cda6c8a26e..36a2d9476358acf4c8b38dd9529b0429084638c7

---

From: Nick Banks <[email-masked]>
Date: Mon, 24 Jun 2019 09:50:46 -0700

nibanks approved this pull request.

Minor nit, but looks good.

> @@ -2859,13 +2859,16 @@ valid frames? -->
 
 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are
+limits on how frequently the can be sent.  An endpoint MUST NOT send more than

```suggestion
limits on how frequently they can be sent.  An endpoint MUST NOT send more than
```

-- 
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/2794#pullrequestreview-253533455

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 09:55:33 -0700

4f2130e2c279efb01baa5789aca13ba364da00ee  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/2794/files/36a2d9476358acf4c8b38dd9529b0429084638c7..4f2130e2c279efb01baa5789aca13ba364da00ee

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 24 Jun 2019 13:24:16 -0700

erickinnear approved this pull request.

Text looks good, just noticed a few minor whitespace nits while reading through.

 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are
+limits on how frequently they can be sent.  An endpoint MUST NOT send more than
+one packet containing only an ACK frame per received ACK-eliciting
+packet(one containing frames other than ACK and/or PADDING).  An endpoint

```suggestion
packet (one containing frames other than ACK and/or PADDING).  An endpoint
```

 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are
+limits on how frequently they can be sent.  An endpoint MUST NOT send more than
+one packet containing only an ACK frame per received ACK-eliciting
+packet(one containing frames other than ACK and/or PADDING).  An endpoint
+MUST NOT send a packet containing only an ACK frame in response to a
+non-ACK-eliciting packet(one containing only ACK and/or PADDING frames),

```suggestion
non-ACK-eliciting packet (one containing only ACK and/or PADDING frames),
```

-- 
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/2794#pullrequestreview-253637540

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 13:21:43 -0700

d8f77e8c64f79eb4f23beb95bd95bcc1f02e14a4  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/2794/files/4f2130e2c279efb01baa5789aca13ba364da00ee..d8f77e8c64f79eb4f23beb95bd95bcc1f02e14a4

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 13:21:51 -0700

233d0c522e16cedadfb4c89d7ccddcae576eda59  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/2794/files/d8f77e8c64f79eb4f23beb95bd95bcc1f02e14a4..233d0c522e16cedadfb4c89d7ccddcae576eda59

---

From: ianswett <[email-masked]>
Date: Tue, 25 Jun 2019 15:35:53 -0700

09ee3ebc938c58016d7c81eaec22dc2f1b8cb454  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/2794/files/233d0c522e16cedadfb4c89d7ccddcae576eda59..09ee3ebc938c58016d7c81eaec22dc2f1b8cb454

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 21:03:50 -0700

Some tweaks, but this is good.

 ### Sending ACK Frames

Is this section missing an intro?

> An endpoint sends an ACK frame to indicate that it has received and processed packets.  Sending ACK frames is the primary mechanism for advancing the state of a connection.

Happy to take this to another issue...

 ### Sending ACK Frames
 
-An endpoint MUST NOT send more than one packet containing only an ACK frame per
-received packet that contains frames other than ACK and PADDING frames.
-An endpoint MUST NOT send a packet containing only an ACK frame in response
-to a packet containing only ACK or PADDING frames, even if there are packet
-gaps which precede the received packet. This prevents an indefinite feedback
-loop of ACKs. The endpoint MUST however acknowledge packets containing only
-ACK or PADDING frames when sending ACK frames in response to other packets.
+Packets containing only ACK frames are not congestion controlled, so there are
+limits on how frequently they can be sent.  An endpoint MUST NOT send more than
+one packet containing only an ACK frame per received ACK-eliciting packet
+(one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT
+send a packet containing only an ACK frame in response to a non-ACK-eliciting
+packet (one containing only ACK and/or PADDING frames), even if there are
+packet gaps which precede the received packet. This prevents an indefinite

```suggestion
packet gaps which precede the received packet. Limiting the sending of ACK
frames avoids creating an indefinite feedback loop of acknowledgements,
which could prevent the connection from ever becoming idle.
```
Apologies for the multi-line suggestion.

> @@ -2883,16 +2886,21 @@ needing acknowledgement are received.  The sender can use the receiver's
 
+An endpoint that is only sending acknowledgements will not receive
+acknowledgments from its peer unless those acknowledgements are included in
+packets with ACK-eliciting frames.  A sender SHOULD bundle ACK frames with
+other frames when possible.

Maybe instead:

> Though it sending an ACK frame in every packet can be inefficient, a sender SHOULD send ACK frames in ACK-eliciting packets that it sends.

Which leads to a difficult question: how often do you send an ACK frame when you aren't receiving ACK-eliciting packets?  We've agreed to make it possible to use the specs to build an "decently performant" stack.  Is this a point that isn't important, or is there a need for specific advice?

-- 
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/2794#pullrequestreview-254370629

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 30 Jun 2019 23:27:00 -0700

igorlord commented on this pull request.

+feedback loop of acknowledgements, which may prevent the connection from ever
+becoming idle. The endpoint MUST however acknowledge non-ACK-eliciting packets
+when sending ACK frames in response to other packets.

Is "The endpoint MUST however acknowledge non-ACK-eliciting packets when sending ACK frames in response to other packets." necessary?  This is simply saying that ACK frames should ACK received packets.

-- 
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/2794#pullrequestreview-256148292

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 30 Jun 2019 23:34:50 -0700

### Sending ACK Frames

So if the stack _really_ wants to ACK some non-ACK-eliciting packet, ACK+PING is ok?  And if ACK+PING is not ok, then ACK+MAX_DATA(repeat latest value) is ok?

My point is that maybe this MUST ought to be replaced with a SHOULD to avoid people having to play these games, when they really want to do so.  (SHOULD still means do it unless you have a great reason not to.)

-- 
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/2794#pullrequestreview-256150592

---

From: Igor Lubashev <[email-masked]>
Date: Sun, 30 Jun 2019 23:44:28 -0700

> How often do you send an ACK frame when you aren't receiving ACK-eliciting packets?

The text above ("An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ACK-eliciting packet") suggests a resolute "never", unless you bundle it with some useless ACK-eliciting frame. (See my comment above.)

The text here is suggesting that when a stack is sending a packet with an ACK-ecliciting frame, it should include an ACK frame for the previously unacknowledged non-ACK-eliciting packet.

-- 
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/2794#discussion_r298898641