Subject: Re: [quicwg/base-drafts] When/how often to send ACK frames (#230)

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 07:01:49 +0000 (UTC)

@ianswett, I forgot to ask something.

Say you make the configurable parameters (the ratio of ACK-only packets to acknowledgments, the delayed acknowledgment timer) known.  And say you define two new transport parameters, one for each.  What does the recipient of that information do with this newly acquired knowledge?

-- 
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/230#issuecomment-322114063

---

From: mirjak <[email-masked]>
Date: Mon, 14 Aug 2017 03:10:23 -0700

In TCP this is would be useful to do a more appropriate RTT and RTO estimation. However, in QUIC you have more fine grained timing information in the ACK frame itself, so maybe that's actually not that useful anymore. However, there is a trade-off between overhead and responsiveness (of †he congestion control). I think it would actually be useful to some kind of negotiation, where the data sender/ack receiver can specify a min and may ack rate, because that peer a) might know something about any access link restrictions (-> don't send more ACK than this because otherwise it will overload my link), and b) know the congestion control use (my cc scheme needs at least an ack every x packets to function correctly).

-- 
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/230#issuecomment-322152628

---

From: Al Morton <[email-masked]>
Date: Mon, 14 Aug 2017 15:54:10 +0000 (UTC)

Adding to @mirjak point on negotiation: c) peer might know about their access link loss conditions, and potentially improve responsiveness by preferring an ACK ratio approaching 1:1. 

-- 
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/230#issuecomment-322229425

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Aug 2017 21:58:05 +0000 (UTC)

@acmacm, @mirjak, were you talking about ACK ratios for regular packets?  Because the discussion was originally about ACK ratios for packets that only contain ACK frames (and padding).

-- 
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/230#issuecomment-322321300

---

From: Al Morton <[email-masked]>
Date: Tue, 15 Aug 2017 01:04:43 +0000 (UTC)

Hi @martinthomson, Sorry for the noise, I see now that you narrowed your question to a part of @ianswett 's Mar 2 statement on ACK of ACKs ratio.  

-- 
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/230#issuecomment-322350034

---

From: mirjak <[email-masked]>
Date: Tue, 15 Aug 2017 10:52:19 -0700

I actually didn't distinguish this. However, you are right that if you only send an ACK there might be scenarios were you'd like to maintain a low rate, e.g. to not wake up the radio to often... on the other hand if you receive data you can also send out an ACK that is queued to be send out... 

-- 
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/230#issuecomment-322539448

---

From: ianswett <[email-masked]>
Date: Tue, 15 Aug 2017 12:04:21 -0700

Knowing the delayed ack timer allows you to set timers for TLP and RTO without creating spurious retransmits, because the ack timer can be incorporated into the min timeout when there's only one packet outstanding.    See the recovery doc(https://tools.ietf.org/html/draft-tsvwg-quic-loss-recovery-00), section 3.1.

Currently most TCP implementations have to use a very conservative min TLP timeout and RTO because they assume the peer likely uses a 100 or 200ms delayed ack timer.

I don't think knowing the ratio tells you much of interest, and it's fairly easy to just observe, but Mirja's right that some congestion control schemes deal better with stretch acks than others.  That being said, ideally congestion controls should deal with them anyway, since they are created by other network elements, so I don't see a large need to communicate this to the peer.

For related info, see https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00

-- 
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/230#issuecomment-322558649