Subject: [quicwg/base-drafts] ACKing ACK (#291)

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Feb 2017 01:02:28 -0800

The text says:

> However, since it is possible that an endpoint might only send packets containing ACK frames (or other non-retransmittable frames), the receiving peer MAY send an ACK frame after a reasonable number (currently 20) of such packets have been received.

"currently 20" seems pretty arbitrary.  That smells like something from the Google QUIC implementation.  We should be more concrete about this, if that behaviour even makes sense.

If an endpoint is receiving nothing but ACKs but is sending itself, then acknowledging those ACKs is probably fine.

An endpoint with nothing to say can generate a lot of ACKs over time, but if both endpoints are being quiet other than ACKs, it's probably time to shut up entirely.  Maybe we should say that the peer SHOULD generate an ACK frame only if it has other frame types to send.

Limiting the number of PING frames that a peer will respond to is a separate issue, and may motivate a limit with a number attached to it.

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

---

From: ianswett <[email-masked]>
Date: Fri, 10 Feb 2017 11:56:18 -0800

Your nose is correct.  That being said, acking every 20 acks has worked out relatively well, so it may make sense to change this to "the receiving peer SHOULD send an ACK frame after 20 ack only packets."  

If both endpoints are being quiet, the rule that "a receiver MUST NOT generate an ack in response to every packet containing only ACK frames." causes them to stop sending packets quite quickly.  The recommended acking behavior could be specified more explicitly, either here or in the recovery doc, if you think it's warranted.

What's the motivation for limiting PING 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/issues/291#issuecomment-279050032

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Feb 2017 15:49:04 -0800

So the current text recommends throttling back on ACK when you are sending lots of packets.  The 20 packet thing keeps the rate low, but it is too arbitrary.  I can justify sending an ACK when you have other things to send, I can justify slowing the rate of ACK generation when you have nothing of value to acknowledge, but I can't justify the specific number.  Anything above 1 probably has the desired effect.

If you aren't careful, PING can waste time and bandwidth, especially since it demands access to the fast path.  Limiting the number that you will respond to is a DoS mitigation.

-- 
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/291#issuecomment-279264415

---

From: hardie <[email-masked]>
Date: Wed, 15 Feb 2017 13:58:14 -0800

Forgive the stupidity on my part, but why do PING frames really need access to the fast path? If a peer sends a PING to detect liveness and reachability, any other packet arriving will serve as a demonstration of that, right?  So the ACK of PING could be serviced right after the PING arrives (if things are quiescent) or after other frames bound to the same peer, and still get the same demonstration at the peer.  Or am I missing something?

-- 
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/291#issuecomment-280153368

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Feb 2017 15:57:21 -0800

Presumably because they can also be used to get a transit time measurement, though any other ACK-able frame would also provide the same effect.  That inclines me toward PING not being higher priority than anything else.  PING is the frame you send when you want to get an ACK, but aren't sending anything ACKable.  If you are, why did you send it?  If you aren't, there's no interference.

-- 
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/291#issuecomment-280182168

---

From: ianswett <[email-masked]>
Date: Thu, 16 Feb 2017 08:27:59 -0800

Now that I've thought about it more, I think the best rule is to not ack acks, and if the peer wants an RTT measurement, it can use a PING frame.  Acking acks just feels odd.  So I suggest we remove the text about acking every 20 acks.

In regards to limiting PING frames, there are lots of ways to waste time and bandwidth.  In TCP or QUIC, you can send a bunch of packets with single byte payloads, which the peer would also ack.  I'm not sure what you mean about fast path?  A PING frame would be acked at whatever rate other ACK-able packets are.  

-- 
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/291#issuecomment-280381139