Subject: [quicwg/base-drafts] MUST NOT bundle, etc. (#3853)

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 19:13:10 -0700

> A receiver MUST NOT bundle an ack-eliciting frame with packets that would
otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
acknowledgements.

This text seems weird. Suppose I have an implementation which tries to send out data packets on a specific clock (e.g., one per second). This isn't totally unrealistic for media. Now suppose my ACK delay timer fires and I want to send an ACK. This text would prohibit my from sending the data packet early to save packets. Surely that's not what's intended.

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

---

From: Christian Huitema <[email-masked]>
Date: Tue, 07 Jul 2020 21:12:53 -0700

I think this is in reaction to the practice of bundling a ping with an ack to trigger an ack of ack. Yes, if both peers bundle a ping with every ack you would get an infinite ping pong. But you would have to be crazy to do that. Plus, bundling a ping with every Nth ack for N > 1 is actually a good way to trigger ack of ack.

-- 
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/3853#issuecomment-655271992

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 22:06:27 -0700

This has always been hard to capture.  In short, you can't only send ack-eliciting packets to acknowledge.

> An endpoint MUST NOT send packets that are exclusively ack-eliciting as this can result in an infinite feedback loop.  It is necessary to send packets that are not ack-eliciting to allow the connection to become idle.

-- 
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/3853#issuecomment-655287113

---

From: Christian Huitema <[email-masked]>
Date: Tue, 07 Jul 2020 23:14:25 -0700

@martinthomson I think part of the issue is the double negation in "MUST NOT send packets that are exclusively ack-eliciting", which makes it kinda hard to grasp by non-natives. Something like "end points MUST NOT force all their packets to elicit an acknowledgement" would be easier.

-- 
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/3853#issuecomment-655310166

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 23:21:42 -0700

So the above or below is OK?

> An endpoint MUST NOT send only ack-eliciting packets as this can result in an infinite feedback loop. It is necessary to send packets that are not ack-eliciting to allow the connection to become idle.

-- 
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/3853#issuecomment-655312891

---

From: Christian Huitema <[email-masked]>
Date: Wed, 08 Jul 2020 07:14:05 -0700

No, I don't think that works. You are speaking of generic ack-eliciting packets, or not, but the problem is much better described and understood if you make a specific statement about ack, ack of ack, and ack loops. You may want to generalize after that to other non ack eliciting frames, but the only such in the main spec are path challenges, so that's not a very high priority.

-- 
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/3853#issuecomment-655546796

---

From: ianswett <[email-masked]>
Date: Wed, 08 Jul 2020 14:04:25 -0700

It's not really the bundling that's the issue, but the idea that one shouldn't send extra ack-eliciting frames when sending an ack.

This isn't shorter, but how about:
"A receiver MUST NOT generate and bundle an ack-eliciting frame with packets that would
otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements."

-- 
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/3853#issuecomment-655756395

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 14:13:11 -0700

On Wed, Jul 8, 2020 at 2:04 PM ianswett <[email-masked]> wrote:

> It's not really the bundling that's the issue, but the idea that one
> shouldn't send extra ack-eliciting frames when sending an ack.
>
> acknowledgements."
> You are receiving this because you authored the thread.
>
>
I feel like this has the same problem as before.

I would suggest that part of the issue here is that we are trying to make
something really crisp. Looking at the rest of the graf, where we
actually endorse this practice, I suggest we do:

  A receiver that sends only non-ack-eliciting packets, such as ACK frames,
might
  not receive an acknowledgement for a long period of time.  This could
cause the
  receiver to maintain state for a large number of ACK frames for a long
period of
  time, and ACK frames it sends could be unnecessarily large.  In such a
case, a
  receiver could bundle a PING or other small ack-eliciting frame to elicit
an ACK from the peer. Caution: If receivers add
  additional ack-eliciting frames to every ACK, this would create
  an infinite feedback loop of acknowledgements. Therefore, receivers SHOULD
  only do this occasionally, such as once per round trip.

-- 
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/3853#issuecomment-655760231

---

From: Christian Huitema <[email-masked]>
Date: Wed, 08 Jul 2020 17:01:02 -0700

Alomost there. I like EKR's text, except for the once per round trip part. Don't do that, because it leads to a loop of round trip period.

-- 
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/3853#issuecomment-655818057

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 19:22:08 -0700

On Wed, Jul 8, 2020 at 5:00 PM Christian Huitema <[email-masked]>
wrote:

> Alomost there. I like EKR's text, except for the once per round trip part.
> Don't do that, because it leads to a loop of round trip period
>

That 1-RTT thing came from the previous text, so I was just retaining it. I
have no personal opinion.

-- 
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/3853#issuecomment-655856942

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Jul 2020 12:30:36 -0700

I also touched this text in #3805; there was previously an "all" that dramatically changes the meaning of the restriction that got dropped somewhere, so I put it back.

> A receiver MUST NOT send an ack-eliciting frame in **all** packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements.

The point is that it's okay to toss a PING in to your ACK-only packets once in a while so you can clear out old ACK ranges, but you shouldn't do that every time you send an ACK.

-- 
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/3853#issuecomment-656310128