Subject: [quicwg/base-drafts] Allow removal of ACK blocks that are in flight (#917)

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Nov 2017 05:30:41 +0000 (UTC)

The discussion in #907 seemed to conclude that it was OK to not send all acknowledgments all the time.  That PR only mentions removal of ACK blocks based on them having been acknowledged, but did not include the other option, which is to not include ACK blocks that are in flight.

There's value in sending acknowledgments more often than once per round trip (timeliness of ACK delivery is tantamount), but there also could be some value in reducing the size of ACK frames if the same ACK block has been sent multiple times already in outstanding packets.

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

---

From: MikkelFJ <[email-masked]>
Date: Sun, 12 Nov 2017 07:08:43 +0000 (UTC)

I think the multiple ack frames issue was closed, but there is still no clarification on how to handle a situation where ACK's will not fit into a single frame, or even MTU. Even if unlikely, implementations need guidelines. How, and when, to not ack certain packets applies here.

-- 
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/917#issuecomment-343718005

---

From: ianswett <[email-masked]>
Date: Sun, 12 Nov 2017 08:42:24 +0000 (UTC)

I think the existing text is mostly sufficient(though I realize it's a bit redundant at the moment, which I'll fix).  I really do not advise some clever scheme where you send an ack block once and then then stop sending it for some arbitrary period of time and then start again, so I don't want to write text implying I'd recommend it.

There is still work to be done to add more discussion of when to send acknowledgements and what to include in them, but it was decided in Seattle that the transport draft should focus on the boundaries of what the receiver should do and the recovery draft can discuss the nuances and optimizations that are possible with considerations about their pros and cons.  That work is tracked in #230

"To limit receiver state or the size of ACK frames, a receiver MAY limit the number of ACK blocks it sends. A receiver can do this even without receiving acknowledgment of its ACK frames, with the knowledge this could cause the sender to unnecessarily retransmit some data. When this is necessary, the receiver SHOULD acknowledge newly received packets and stop acknowledging packets received in the past. Removing ack blocks before the peer has received them increases the chances the peer never received an acknowledgement, will declare the packet lost, and spuriously retransmit information."

-- 
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/917#issuecomment-343722015

---

From: Mike Bishop <[email-masked]>
Date: Sun, 12 Nov 2017 14:13:52 +0000 (UTC)

Can you help me understand the pathological case when something is ACK’d, omitted, then ACK’d again?  If the original ACK gets through, the sender should ignore the second one.  If the original ACK gets lost, it looks to the sender like a severely delayed packet and it will realize the retransmission was spurious (if it still has data), but might update the congestion controller with the un-loss event.  That doesn’t seem so bad at first glance.

From: ianswett [mailto:[email-masked]]
Sent: Sunday, November 12, 2017 4:42 PM
To: quicwg/base-drafts <[email-masked]>
Cc: Subscribed <[email-masked]>
Subject: Re: [quicwg/base-drafts] Allow removal of ACK blocks that are in flight (#917)

There is still work to be done to add more discussion of when to send acknowledgements and what to include in them, but it was decided in Seattle that the transport draft should focus on the boundaries of what the receiver should do and the recovery draft can discuss the nuances and optimizations that are possible with considerations about their pros and cons. That work is tracked in #230<https://github.com/quicwg/base-drafts/issues/230>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/917#issuecomment-343722015>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hYPDupg70sZEpl27EPsg_D_5t6POks5s1q9ugaJpZM4Qaw74>.

-- 
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/917#issuecomment-343740140

---

From: MikkelFJ <[email-masked]>
Date: Sun, 12 Nov 2017 14:55:16 +0000 (UTC)

> Can you help me understand the pathological case when something is ACK’d, omitted, then ACK’d again? 

With sufficiently many holes, e.g. loosing every second package because one of two routing paths are faulty, the number of ack blocks could grow large enough to force having to drop some due to limitations in space dedicated to ACK frames.

Eventually the faulty link unblocks and packets gets through. A number of destinct ACK blocks collapses into fewer blocks because the gaps disappear.

Avoiding ACK'ing already acked packets might keep the ACK block unnecessarily high.

-- 
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/917#issuecomment-343742867

---

From: ianswett <[email-masked]>
Date: Sun, 12 Nov 2017 22:23:41 +0000 (UTC)

@MikeBishop It's not pathological, but the spurious retransmit could be avoided by sending the ack block in all 3 acks.  The goal here is very much to avoid spurious retransmits.  You could ack every packet exactly once and the transport would still function correctly.

Also realize that as @mikkelfj mentions, most packets are in contiguous blocks, so continuing to ack old packets commonly has zero cost in terms of bytes on the wire.

-- 
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/917#issuecomment-343773166

---

From: Mike Bishop <[email-masked]>
Date: Sun, 12 Nov 2017 23:53:12 +0000 (UTC)

It seems like we're talking about different cases, though.  Or you're using examples that seem to argue the other way.

As @mikkelfj describes, if you have too many ACK blocks (e.g. because that section experienced loss/delays and has many gaps), you might choose to omit some older blocks from your ACK frame.  But once packets arrive and the contiguous blocks become larger, you can resume ACKing them because you have fewer blocks to express.

Basically, I see the argument against simply forgetting packets that haven't been ACK-of-ACK'd yet; you're essentially fabricating loss.  But it seems like it's a perfectly valid thing to selectively include a subset of the packets you know about in your ACK frame if size is an issue.

-- 
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/917#issuecomment-343779225

---

From: ianswett <[email-masked]>
Date: Mon, 13 Nov 2017 01:00:47 +0000 (UTC)

Agreed, and I think that's what the text says, particularly after #918, but with the guidance that if you're going to stop acking packets, it's best to stop acking the older ones vs newer ones.

-- 
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/917#issuecomment-343784012

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Nov 2017 01:48:39 +0000 (UTC)

>From #918,
> Therefore, receivers SHOULD NOT stop sending an ack block and then start sending it again substantially later in an effort to save bytes sent.

This seems to be saying that you SHOULD NOT do exactly the thing we just agreed harms nothing.  So I'm a little confused.

-- 
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/917#issuecomment-343788628

---

From: ianswett <[email-masked]>
Date: Mon, 13 Nov 2017 01:51:58 +0000 (UTC)

The hope is to provide guidance about what one should and should not do.  Certainly you can stop acking a packet and then start acking it later, but the later acks are likely to be a waste of bytes(unless you start acking again because it actually saves bytes of course).

It's also possible we're just confusing each other :)

-- 
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/917#issuecomment-343788994

---

From: MikkelFJ <[email-masked]>
Date: Mon, 13 Nov 2017 06:26:07 +0000 (UTC)

Perhaps this divergent view can be resolved by encouring transmissing older ACK's to reduce gaps, but keep an oldest ACK packet number that progresses steadily and beyond which no ACK is transmitted.

This will not grow the ACK ranges because that limit does not introduce any gaps. This is essentially what I have in my draft implementation.

-- 
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/917#issuecomment-343825595

---

From: ianswett <[email-masked]>
Date: Mon, 13 Nov 2017 06:32:34 +0000 (UTC)

I was intending to discuss ack behavior in detail in the recovery draft, where I will go into approaches like what you're outlining and a few others that have been suggested.  But yes, your approach is very sensible.

-- 
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/917#issuecomment-343826560