Subject: [quicwg/base-drafts] ACK retransmission (#63)

From: Martin Thomson <[email-masked]>
Date: Thu, 01 Dec 2016 15:50:20 -0800

We have rules about retransmission of STREAM frames.  ACK has similar properties in terms of what needs to be retransmitted.  Once an ACK has been acked, what should a sender do when constructing future ACK messages?

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

---

From: ianswett <[email-masked]>
Date: Thu, 01 Dec 2016 16:57:12 -0800

ACKs are cumulative, therefore you would never retransmit them.  This is similar to TCP.

Or possibly you're asking a different question?

-- 
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/63#issuecomment-264342924

---

From: Mike Bishop <[email-masked]>
Date: Fri, 02 Dec 2016 10:01:33 -0800

This seems bound to the possible removal of STOP_WAITING (#66).  STOP_WAITING effectively ACKs the ACK, informing the receiver that the sender has all the loss/arrival information needed about those frames.  Hypothetically, you could infer something equivalent with ACKs of packets containing 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/63#issuecomment-264519594

---

From: martinduke <[email-masked]>
Date: Mon, 05 Dec 2016 15:08:57 -0800

sack blocks aren't really cumulative under some interpretations; hence my confusion. For instance I might ack packet 1 and SACK 3,4,5. Do I continue to send this information in subsequent ACK frames, leading to potentially very long ones? Or do I just send it once and leave it out of ACK frames that report, say SACK 7,8,9?

If I leave them out, then by extension I should keep track of what acks/sacks went out in each packet, so that if the packet containing the ack is itself acknowledged I never have to report them again.

I am unclear as to how the logic of a protocol without STOP_WAITING would work, so it's clear that either I missed something in the draft or it's just not written.

-- 
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/63#issuecomment-265008131

---

From: ianswett <[email-masked]>
Date: Mon, 05 Dec 2016 16:22:07 -0800

The guideline is to continue to ack packets until a stop waiting frame says to not ack them anymore.  However, a receiver can also stop acking packets due to memory constraints, running out of ranges, or potentially other reasons.  Section 6.2 of the transport doc does go into this, but it could be a bit clearer, and a clarifying example may be helpful.  
https://tools.ietf.org/html/draft-ietf-quic-transport-00#section-6.2

In terms of how the logic would work without STOP_WAITING, it's completely non-obvious in the current specs, which is why I need to write it up.

-- 
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/63#issuecomment-265022140

---

From: martinduke <[email-masked]>
Date: Mon, 05 Dec 2016 16:37:25 -0800

Ah. OK. My first hack at implementing this did what you describe, then I realized that the alternate approach would save lot of bytes, though with more bookkeeping. I see now that the words are there in Section 6.2 but it would be nice to have a more explicit requirement, e.g. "A receiver SHOULD repeat SACK blocks until those packets are covered by a STOP_WAITING".

To be honest, I think tracking which of my acks have been acked would reduce the control overhead of the protocol without requiring any wire format changes. But this might all be moot if STOP_WAITING dies.

-- 
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/63#issuecomment-265024921

---

From: ianswett <[email-masked]>
Date: Tue, 06 Dec 2016 06:19:51 -0800

Tracking acks of acks is how STOP_WAITING dies.

-- 
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/63#issuecomment-265160673

---

From: martinduke <[email-masked]>
Date: Tue, 06 Dec 2016 08:12:07 -0800

I always thought the main purpose of STOP_WAITING was to stop acking lost packet numbers, which of course will never be retransmitted. Will the receiver somehow infer this instead?

-- 
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/63#issuecomment-265192041

---

From: Mike Bishop <[email-masked]>
Date: Tue, 06 Dec 2016 08:15:06 -0800

And it is -- but the reason you can stop ACKing them is that the original sender has enough information to know they're lost.  They can tell you this explicitly (STOP_WAITING), or you can infer it by knowing which of your ACKs made it through.

-- 
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/63#issuecomment-265192990

---

From: martinduke <[email-masked]>
Date: Tue, 06 Dec 2016 08:19:46 -0800

OK, so because we know the loss detection algorithm we can infer what the sender has given up on.  That sounds like it might be problematic when the loss detection is timer-based. Moreover, it turns loss detection into something that must be carefully negotiated between endpoints, rather than simply innovating on one end.

Perhaps I should give you a chance to write it up before trying to poke holes in 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/63#issuecomment-265194368