Re: Is CONNECTION_CLOSE frame Ack-eliciting？

[Marten Seemann <[e-mail]>]

It doesn't really make sense to send a CONNECTION_CLOSE frame in response
to a CONNECTION_CLOSE, since in the closing state an endpoint retains "only
enough information to generate a packet containing a CONNECTION_CLOSE frame
and to identify packets as belonging to the connection", i.e. an endpoint
won't even open the packet (but it might reply with another
CONNECTION_CLOSE).
Of course, and endpoint can send as many packets after this as it wants
(there's no way it could be penalized for misbehaving), although I'm not
sure why we're explicitly allowing sending CONNECTION_CLOSE as a response.

I'm not really sure what the benefit is of sending an ACK frame bundled
with a CONNECTION_CLOSE. There's nothing the receiving peer can do in
reaction to receiving that ACK - the connection is already closed.
Furthermore, it would be wrong to conclude that all stream data has been
processed by the application. An ACK for a STREAM frame only means that the
STREAM frame was processed by the QUIC stack, not by the application.

On Thu, Jun 6, 2019 at 12:03 AM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> 10.3: "After receiving a CONNECTION_CLOSE frame, endpoints enter the
> draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send
> a single packet containing a CONNECTION_CLOSE frame before entering the
> draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if
> appropriate."
>
> On 5 June 2019 at 17.58.19, Ian Swett ([e-mail]) wrote:
>
> 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？
>>
>>