Subject: [quicwg/base-drafts] What does it mean to acknowledge something? (#341)

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 14:27:11 -0800

We're starting to see a few cases where ACK frames are being used to close the loop on things.  But that raises questions like "if a peer acknowledges a packet containing a GOAWAY, does that mean I can assume that stream above the mentioned number are now closed at their end?"

I think that we need to state what the rule is, and it should be simple.  An acknowledgement for a packet implies that all QUIC-level control messages have been read and processed.

This includes PING, ACK, RST_STREAM, GOAWAY, etc...  I think that it also has to include FIN bits on STREAM frames.  That implies that the *transport* must have finished handling all the messages.

The application protocol might not have consumed the data from STREAM frames, but that is the only thing that is considered outstanding when a packet is acknowledged.  We have a special sort of acknowledgment for data: flow control credits.

If we add features that include special acknowledgement (like flow control), then those would be excluded, but that would be explicitly stated.  Otherwise, if it is in the transport and it is acknowledged, then it has been processed by the receiver.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 23 Feb 2017 14:38:30 -0800

On Thu, Feb 23, 2017 at 2:27 PM, Martin Thomson <[email-masked]>
wrote:

> I think that we need to state what the rule is, and it should be simple.
> An acknowledgement for a packet implies that all QUIC-level control
> messages have been read and processed.
>
>
​SGTM! ​

-- 
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/341#issuecomment-282144859

---

From: ianswett <[email-masked]>
Date: Thu, 23 Feb 2017 14:42:31 -0800

I think stream frames and FIN bits are a maybe in my mind, but I definitely agree on processing control frames.

-- 
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/341#issuecomment-282145873

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Feb 2017 15:25:15 -0800

FIN bits are already special-cased -- you can't effect the stream state change until you've gotten all STREAM frames on that stream.  And they're flags on a STREAM frame, so if we say that STREAM frames aren't part of this, FIN flags are implicitly included.

I would favor stating that *all* frames have been processed, but clarify that means the STREAM frames have been queued for delivery with no guarantees about having actually delivering them.  (And being queued also doesn't guarantee much if there are gaps.)  Alternately, state that everything except the STREAM frames have been processed.

-- 
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/341#issuecomment-282154991

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Feb 2017 15:51:09 -0800

I think that Mike's view here is best.  That is, you have to have ingested all the frames in the packet before acknowledging.  For data on a stream, that means putting it into a buffer, but it also means that you might transition the stream to closed if all the data is in.

I'd rather have that and allow an endpoint to *know* that a completely delivered stream no longer counts against the concurrent stream limit.  Creating an exemption for STREAM frames leaves a messy hole.

-- 
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/341#issuecomment-282159897

---

From: ianswett <[email-masked]>
Date: Thu, 23 Feb 2017 16:34:07 -0800

Agreed, you must have ingested all frames in a packet before acking it.  We had subtly different behavior early on in QUIC and it was an enormous and unnecessary complication.

My comment about the fin bit and stream frames possibly not being included was because other stream frames may not have arrived, and that when a packet is acked, that doesn't change available flow control window.

-- 
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/341#issuecomment-282167434