What does it mean to acknowledge something?

[martinthomson]

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.

[RyanTheOptimist]

On Thu, Feb 23, 2017 at 2:27 PM, Martin Thomson ***@***.***> 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! ​

[ianswett]

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

[MikeBishop]

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.

[martinthomson]

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.

[ianswett]

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.