Subject: [quicwg/base-drafts] Offload should not delay ACKs (#4001)

From: ianswett <[email-masked]>
Date: Sun, 16 Aug 2020 12:53:52 -0700

The existing text mostly covers this, but I don't think it's always as clear as it could be.

If one is doing various offloads(pacing/crypto/etc) and those cause the sender to decide to send a batch of packets at once, the sender should not have to wait until all those packets are released to send an ACK.

The simple way to think about this is "ACK-only packets don't affect acknowledgement behavior", which matches with TCP and most of our existing text.

I think this will end up being editorial and I believe the only clarification necessary is #4000 but I'd appreciate other peoples thoughts on whether this is something worth thinking about and whether there are any other changes necessary.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Aug 2020 16:24:05 -0700

I share the view that this has been the intent, and that it is editorial.

Loss recovery is an interaction between sender sending data vs. receiver sending acks. We might have two endpoints doing loss recovery at the same time, when both sides are sending data. But that should not affect how loss recovery works.

-- 
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/4001#issuecomment-674591464

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Aug 2020 22:05:42 -0700

In https://github.com/quicwg/base-drafts/pull/4000#issuecomment-674638169, @martinthomson asks:
> How do you tell if the absent packets are ack-eliciting? I mean, most scenarios we use this definition are for the receiver, which can't know whether a missing packet is ack-eliciting.

I think we need to think about two possibilities: an ack-eliciting packet overtaking ack-only packet, and an ack-only packet overtaking an ack-eliciting packet.

If the former happens, the receiver can do nothing but send an immediate ack, because it cannot tell if the yet-missing packet is ack-only. But in the opposite case, the receiver can tell that it was an ack-only packet, because it has already received that packet.

IIUC, @ianswett's point is that we'd frequently see the latter when pacing is used, and therefore that we should address the issue.

IMO, this issue is an artifact of us using one packet number space for loss recovery in both directions. The problem cannot be cleanly solved unless we use different packet number spaces for ack-eliciting packets and ack-only packets. That said, I do think that it is a good idea to minimize the impact of the problem, and that the proposed clarification works fine in that respect.

-- 
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/4001#issuecomment-674657546

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Aug 2020 22:19:55 -0700

That's a reasonable analysis of this situation.  That is also consistent with what our stack implements.  That is, we only ever send an immediate acknowledgement when we receive ack-eliciting packets.  I can't see how you would do otherwise, frankly.

However, I think that attempting to define "out-of-order" is the problem.  I just searched the transport document for this and we don't use the definition.  Therefore, I suggest that we say what we mean when it comes to describing how to immediately acknolwedge packets.  That is,

> An endpoint SHOULD generate and send an ACK frame without delay when it receives an ack-eliciting packet either:
> * when the packet has a packet number less than any other ack-eliciting packet that has been received; or
> * when the packet has a packet number larger than any other ack-eliciting packet that has been received and there is an apparent gap between that other packet and this packet.

Or something like that.

The out-of-order definition can go.

-- 
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/4001#issuecomment-674661218

---

From: ianswett <[email-masked]>
Date: Mon, 17 Aug 2020 07:51:23 -0700

Good thought on getting rid of 'out-of-order', that should help.

-- 
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/4001#issuecomment-674928019

---

From: Mike Bishop <[email-masked]>
Date: Mon, 17 Aug 2020 08:40:28 -0700

I was about to say we could simplify the second bullet, but that would miss the case of:
- N-3:  last received ack-eliciting packet
- N-2:  lost
- N-1:  ACK-only packet
- N:  Newly received

We want to send an immediate ACK on receipt of N, but not N-1.  Nor do we want one on the late receipt of N-2.

-- 
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/4001#issuecomment-674955231

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 18 Aug 2020 15:15:04 -0700

border-Borderline design, let's run the process for visibility

-- 
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/4001#issuecomment-675746545