Re: Is CONNECTION_CLOSE frame Ack-eliciting？

[Ian Swett <[e-mail]>]

Nick, I agree that bundling an ACK with a CONNECTION_CLOSE is useful, and
our implementation does that as well.

However, it seems like the existing text indicates you'd never expect to
get a CONNECTION_CLOSE in response to a CONNECTION_CLOSE?  Or am I
misreading the text about draining?

On Wed, Jun 5, 2019 at 10:08 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> CONNECTION_CLOSE can be response to CONNECTION_CLOSE and that response can
> contain other frames.. So technically you can ACK a connection close.
>
> Doing so might actually make sense if the original closer take that as a
> signal to drain faster.
>
>
> On 5 June 2019 at 16.00.16, Nick Banks (
> nibanks=[e-mail]) wrote:
>
> Ian,
>
>
>
> I have encountered issues both in local automated tests and during
> interop, where one side gets everything it wants and then cleanly closes
> the connection. The issues arise because the peer hasn’t received the ACK
> for that last exchange. For that reason, winquic always encodes its latest
> ACK state with (always frames before) the CONNECTION_CLOSE frame. This
> doesn’t increase the size of the packet much, and it’s up to the receiver
> if they want to process the ACKs or not; but it helps these kind of
> scenarios.
>
>
>
> A simple example test case:
>
>
>
> Client: Open one bidirectional stream, send data on it, FIN it, and verify
> the peer does the same. Then close the connection.
>
> Server: Accept one bidirectional stream, receive all data on it and echo
> it back. Verify all data is sent successfully.
>
>
>
> The “Verify all data is sent successfully” fails if you don’t send ACKs
> with CONNECTION_CLOSE. So, I personally think it’s a good idea to recommend
> including ACKs. I know it doesn’t provide any guarantees in the presence of
> packet loss, so ideally you don’t design an app protocol on top of this,
> but it does make things a little nicer, IMO.
>
>
>
> Thank,
>
> - Nick
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Ian Swett
> *Sent:* Wednesday, June 5, 2019 6:48 AM
> *To:* Jiuhai Zhang <[e-mail]>
> *Cc:* IETF QUIC WG <[e-mail]>
> *Subject:* Re: Is CONNECTION_CLOSE frame Ack-eliciting？
>
>
>
> Technically, yes.  But connections don't send any packets after processing
> a CONNECTION_CLOSE frame, so you would never receive and ACK for it.
>
>
>
> From:
> https://tools.ietf..org/html/draft-ietf-quic-transport-20#section-10.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-quic-transport-20%23section-10.1&data=02%7C01%7Cnibanks%40microsoft.com%7Ca3e4b3be88064c15350408d6e9bc9185%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953393451363725&sdata=bi9%2FDh3XZuUgM%2B23tC54csAhdE5RQENRTQzgj5%2B%2BPlM%3D&reserved=0>
>
> "The draining state is entered once an endpoint receives a signal that
>
>    its peer is closing or draining.  While otherwise identical to the
>    closing state, an endpoint in the draining state MUST NOT send any
>    packets.  Retaining packet protection keys is unnecessary once a
>    connection is in the draining state."
>
>
>
> On Wed, Jun 5, 2019 at 8:04 AM Jiuhai Zhang <[e-mail]>
> wrote:
>
> In https://tools.ietf.org/html/draft-ietf-quic-recovery-20#section-2
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-quic-recovery-20%23section-2&data=02%7C01%7Cnibanks%40microsoft.com%7Ca3e4b3be88064c15350408d6e9bc9185%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636953393451363725&sdata=420rgTO4Iud8HbpF8KvvANjFfPFP%2BtwAnjVS7KszGb4%3D&reserved=0>
>
> Ack-eliciting Frames:  All frames besides ACK or PADDING are
>
>       considered ack-eliciting.
>
>
>
> Is CONNECTION_CLOSE frame Ack-eliciting？
>
> Should endpoint responds a ACK frame when receiving a CONNECTION_CLOSE frame？
>
>