Subject: [quicwg/base-drafts] Restrict delayed ACKs (#1662)

From: mirjak <[email-masked]>
Date: Tue, 14 Aug 2018 14:28:50 +0000 (UTC)

Currently the transport drafts says:
"Packets containing non-ACK frames MUST be acknowledged immediately or when a delayed ack timer expires."

However, I think the transport draft should set actually boundaries here and not rely on the delayed ack timer defined in another doc. RFC1122 for TCP e.g. says
"A TCP SHOULD implement a delayed ACK, but an ACK should not
be excessively delayed; in particular, the delay MUST be
less than 0.5 seconds, and in a stream of full-sized
segments there SHOULD be an ACK for at least every second
segment."

I guess we can now a days adapt the values a bit but should probably define similar boundaries in the transport draft.

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

---

From: ianswett <[email-masked]>
Date: Tue, 14 Aug 2018 13:55:22 -0700

There's more text on this in the recovery draft, as well as related issue #1428 

Since there is a lot of interaction with recovery here, I'd rather keep as much text as possible in that draft.  I want to keep specific numbers like 0.5 seconds or 2 packets out of this draft, but if we need more text referencing recovery or some other descriptive text, feel free to suggest 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/1662#issuecomment-413012916

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Aug 2018 16:54:56 -0700

This appears to be part of the cluster of issues related to ACK delays.  If someone has a concrete proposal for that, I would like to see that before the interim, so that we can resolve it there.

-- 
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/1662#issuecomment-413052227

---

From: mirjak <[email-masked]>
Date: Wed, 15 Aug 2018 01:55:20 -0700

@ianswett I would like to see that the transport draft sets the normative boundaries while the recovery draft specifies the specifics. This way both drafts are less dependent and could be easier revised in future separately.

@martinthomson I would put recommended numbers in the recovery draft but we can try to put lower and upper boundaries in the transport draft. I actually think something like "SHOULD at least send one ACK per RTT" would be good but that might be hard to implement. I think we can easily agree on an upper bound for the delay timer. I guess we can either go with 0.5 seconds as well or even something lower.

-- 
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/1662#issuecomment-413136116

---

From: ianswett <[email-masked]>
Date: Wed, 15 Aug 2018 05:38:43 -0700

I'm fine with one ack per RTT, since that seems like a sensible minimum.  If we say that, I don't see a need to say 0.5 seconds in transport.

-- 
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/1662#issuecomment-413185027

---

From: mirjak <[email-masked]>
Date: Wed, 15 Aug 2018 06:40:23 -0700

But that would mean you dynamically would need to set the time-out based on your RTT, e.g. kDelayedAckTimeout=min(smoothed_rtt,25)

Is that really what you want? It would make the ack delay at least less predictable for small RTTs...

-- 
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/1662#issuecomment-413200531

---

From: ianswett <[email-masked]>
Date: Wed, 15 Aug 2018 06:45:18 -0700

I think the goal for the transport doc is to define boundaries of reasonable behavior, correct?  If so, I no more than 1 ACK sent in response to a packet and at least 1 ACK per RTT are good boundaries.

I'd like the more detailed text to be in recovery, as I said above.  There are some open issues to improve that text, including the one I reference above.

-- 
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/1662#issuecomment-413201861

---

From: mirjak <[email-masked]>
Date: Wed, 15 Aug 2018 13:47:25 +0000 (UTC)

Yes, boundaries in transport, detailed text in recover. I just meant to say if the boundary is one ack per RTT, the detailed text in recover should say something like kDelayedAckTimeout=min(smoothed_rtt,25)

And I wanted to make sure that that is really what you want...?

-- 
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/1662#issuecomment-413202516

---

From: ianswett <[email-masked]>
Date: Wed, 15 Aug 2018 13:53:47 +0000 (UTC)

Thanks for clarifying.  I think there are potentially two numbers.  One is what the sender is assuming the receiver is using and the other is the value the receiver is using.  I think the receiver should use the value you suggest above with a min(), but I don't think the sender should assume that, since one may have a substantially different value for SRTT than the other.

I'm due to write a fair bit of text in the recovery doc about ACK behavior, so I'm happy to keep this issue open until that text includes mention of this "at least one ack per RTT behavior" and what the sender should and should not assume?

-- 
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/1662#issuecomment-413204392

---

From: mirjak <[email-masked]>
Date: Wed, 15 Aug 2018 06:57:25 -0700

right, I think you only need to say that the sender should assume that to be a max. I guess there is anyway no problem is the ACK is sent faster...

-- 
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/1662#issuecomment-413205423

---

From: mirjak <[email-masked]>
Date: Thu, 16 Aug 2018 01:24:51 -0700

Actually I kept thinking about this and saying "at least one ACK per RTT" would not be addressed with restricting the delayed timer timer for the RTT. What you rather would need to do, is to have another (or just one different?) timer that is started when the last ACK was sent.

-- 
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/1662#issuecomment-413466352

---

From: ianswett <[email-masked]>
Date: Thu, 16 Aug 2018 06:00:58 -0700

If that's what you wanted, you would need that, but if the connection isn't receiving any packets, not sending acks is the right thing, so I think the new clause in the PR: "if new packets needing acknowledgement were received." covers that?

-- 
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/1662#issuecomment-413537115

---

From: mirjak <[email-masked]>
Date: Thu, 16 Aug 2018 08:20:42 -0700

Yes, if you don't receive anything that is fine. However, just using the delayed ack timer would not fulfill the requirement of one ACK per RTT. Assume a scenario where you send packets and you ack the last packet and then send nothing for about one RTT and then send one more packet. In that scenario you should ack immediately because you didn't send an ACK in the last RTT and should not wait for the delayed ack timer to expire.

-- 
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/1662#issuecomment-413582923

---

From: ianswett <[email-masked]>
Date: Tue, 28 Aug 2018 15:16:58 -0700

Closed #1662 via 3f7fc295dbb0026733f0310c4fd7860902b1f098.

-- 
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/1662#event-1814281830