RE: Is CONNECTION_CLOSE frame Ack-eliciting？

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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？