Re: Closing on CONNECTION_CLOSE

[Jana Iyengar <[e-mail]>]

I'm also in favor of the RST model. Subodh -- to your point about
time_wait, this dovetails with a timeout we need to have in place for
regular connection close, where we must allow for retransmissions to be
sent and for responses to peer's retransmissions. (It's what I call
DRAIN_TIME).

So basically, once a connection close is sent, the sender waits for
DRAIN_TIME and then discards state. The receivers sends an ack and
immediately discards state on receipt.

As ekr notes, receipt of this ack could circumvent the DRAIN_TIME timeout.
TCP time wait accounts for network lifetime of packets, which we don't have
to handle, since once both sides are torn down, there's no danger of an old
connection interfering with a new one. That said, I'm still thinking about
if it's possible for an old packet circling the network to create
connection state when received after all state is torn down... If we want
to ensure that doesn't happen, we'd want to account for network lifetime (2
msl).

On Jul 27, 2017 7:59 AM, "Eric Rescorla" <[e-mail]> wrote:

> I just filed a PR for this at:
> https://github.com/quicwg/base-drafts/pull/705
>
> It explicitly permits duplication.
>
> -Ekr
>
>
> On Thu, Jul 27, 2017 at 7:51 AM, Ian Swett <[e-mail]> wrote:
>
>> I would recommend sending an identical packet every time, since there's
>> no value to encrypting a new one with a new packet number, but it increases
>> the amount of state you have to keep and the CPU to respond to spurious
>> packets.
>>
>> On Thu, Jul 27, 2017 at 10:47 AM, Swindells, Thomas (Nokia -
>> GB/Cambridge, UK) <[e-mail]> wrote:
>>
>>> > > However, this isn't that big a deal, because as
>>> > > noted above, you can throw away the connection and just send a stored
>>> > > packet, or alternately, just send public reset (or just go silent).
>>> Should/would you have to generate a newly encrypted packet with a new
>>> packet number each time (as per other retransmissions)?
>>> Or is this a special case because it is the final packet and so doesn't
>>> matter if it is duplicated?
>>>
>>>
>>
>