Re: Is CONNECTION_CLOSE frame Ack-eliciting？

[Ian Swett <[e-mail]>]

Thanks, I missed that.

On Wed, Jun 5, 2019 at 12:03 PM 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？
>>
>>