Subject: [quicwg/base-drafts] Soliciting acks of acks (#836)

From: ekr <[email-masked]>
Date: Thu, 05 Oct 2017 10:25:25 -0700

```   A receiver that is only sending ACK frames will not receive
   acknowledgments for its packets.  Sending an occasional MAX_DATA or
   MAX_STREAM_DATA frame as data is received will ensure that
   acknowledgements are generated by a peer.  Otherwise, an endpoint MAY
   send a PING frame once per RTT to solicit an acknowledgment.
```

If we think this is useful, we should add a flag to ack that says "ack 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/issues/836

---

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 05:02:30 +0000 (UTC)

I would take a very deep breath, or run a couple miles, before proposing adding new flags to the ACK syntax. We already have a ready-made flag -- just add a one-byte PING after the ACK. @ekr , the text that you quoted just points out that in normal operation, even a "pure receiver" will need to send a steady stream of flow control updates, which is sufficient in practice to cause regular ACK of 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/issues/836#issuecomment-335067202

---

From: janaiyengar <[email-masked]>
Date: Fri, 13 Oct 2017 19:54:05 +0000 (UTC)

I don't think we need this. I agree with @huitema, this functionality is already available. From a transport perspective, I don't think there's value in 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/issues/836#issuecomment-336551624

---

From: ianswett <[email-masked]>
Date: Sat, 14 Oct 2017 17:26:24 -0700

Agreed, we should not do 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/issues/836#issuecomment-336676978

---

From: ekr <[email-masked]>
Date: Sun, 15 Oct 2017 00:30:41 +0000 (UTC)

Well, either it's "this happens anyway" or it's "you need to ask for it explicitly". If it's the latter, then it's goofy to have to add some other frame to get it, especially because the code that generates frames has no knowledge of how they will be marshalled into 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/issues/836#issuecomment-336677135

---

From: Christian Huitema <[email-masked]>
Date: Sat, 14 Oct 2017 22:09:41 -0700

Well, my implementation generates ACK "on the fly" as part of sending packets, so I know exactly in which packet the ACK is sent and can easily add a PING if that's really needed. But even if the PING was sent in the next packet, you will still get a cumulative ACK that will "ACK the ACKs".

-- 
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/issues/836#issuecomment-336687028