Subject: [quicwg/base-drafts] When the sender is using standard Reno congestion control, ack every ~2 packets (#1428)

From: ianswett <[email-masked]>
Date: Thu, 07 Jun 2018 01:47:15 -0700

We should recommend acking every 2 packets or something similar when the sender is using Reno or another window based congestion control like Cubic.

Other congestion controllers like BBR are able to tolerate less frequent acking, but those controllers are not standardized and quite a bit more complex.

This makes me a bit sad, since I like acking less frequently, but the recovery doc should be self-consistent.

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

---

From: janaiyengar <[email-masked]>
Date: Sun, 10 Jun 2018 10:40:56 -0700

The receiver doesn't know the sender's congestion controller, so that recommendation is not going to be useful in practice.

The receiver is usually capable of sending acks as frequently as necessary, in response to packet receive events. The sender knows how sensitive it is to the ack ratio, so it needs to suggest the max ratio. I think we need a transport param for 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/1428#issuecomment-396067343

---

From: ianswett <[email-masked]>
Date: Sun, 10 Jun 2018 15:38:42 -0700

To clarify, my proposal is that we should document an acknowledgement approach we expect to work well with the described congestion controller, Reno.  Do you think that would not be useful?

If we want to add a mechanism to indicate to the receiver that acknowledging packets less frequently is ok, then as you said, we need one or more transport parameters.  

What transport parameter(s) do you have in mind? The two I can think of are the max number of packets newly acked at once and the interval between acks in fraction of an RTT or absolute time.  The current BBR approach is very adaptive, so it doesn't need to know the details of the receiver's behavior.  It's not clear to me how other congestion controllers will adapt to this, so it's not clear to me what information they need?

-- 
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/1428#issuecomment-396087604

---

From: janaiyengar <[email-masked]>
Date: Mon, 11 Jun 2018 16:34:12 -0700

The Reno spec is a simple CC for those senders who need something simple and reasonably effective to implement on the send side. I don't think we can afford to specify a receiver that assumes only Reno senders though. Given that senders (such as Google's servers, for instance) will use non-Reno CCs right off the ground, we would want receivers to do something better than simply ack every two packets right off the ground.

Any sender should be adaptive to this, but it's useful to have a knob by which we can control receiver behavior and reduce the number of ACK-only packets that are being sent on the wire. The point of acking every other packet is basically an attempt to reduce the number of ACK-only packets, and we ought to be able to make it more generalizable.

As I mentioned in my earlier comment, I think the sender can specify something like:
ack_ratio: number of retransmittable packets received after which an ack must be sent. 2 by default.

We can also additionally have an ack_delay param that the receiver tells the sender about, but I think that can be a separate issue (and there's already #981).

-- 
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/1428#issuecomment-396419114

---

From: ianswett <[email-masked]>
Date: Mon, 11 Jun 2018 17:23:07 -0700

We shouldn't assume only Reno, but as EKR pointed out, the text should describe something we expect to perform reasonably well.

Yes, let's keep ack delay is a separate issue.  And I completely agree that we don't want to specify only acking every two packets.

If we specify ack ratio, I tend to think it should be in bytes, not packets, but possibly it doesn't really matter?  However, it seems like min number of acks per RTT is just as valuable as max number of bytes received before sending an acknowledgement.  

At the moment, I'm fairly concerned that we are only aware of one congestion controller that deals well with intentional receiver-side aggregation/decimation, and it is ok with any value of ack_ratio.  More important to BBR is getting somewhat regular feedback, ie: at least once per RTT, ideally more often.

-- 
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/1428#issuecomment-396427016

---

From: MikkelFJ <[email-masked]>
Date: Tue, 12 Jun 2018 04:56:41 -0700

I don't know that much about congestion control algorithms, but at some point I made a note of the following:

http://modong.github.io/pcc-page/

-- 
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/1428#issuecomment-396563553

---

From: ianswett <[email-masked]>
Date: Tue, 12 Jun 2018 05:35:38 -0700

Good point, I think PCC(or any other primarily rate based algorithm) would still perform well with a significantly reduced ack rate.

-- 
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/1428#issuecomment-396573284