Re: Closing on CONNECTION_CLOSE

[Eric Rescorla <[e-mail]>]

On Thu, Jul 27, 2017 at 8:35 AM, Jana Iyengar <[e-mail]> wrote:

> 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.
>

Jana,

I'm finding myself a bit confused. Can you perhaps draw me a diagram of
what you mean when
you say "allow for retransmissions to be sent"...?

-Ekr


> 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?
>>>>
>>>>
>>>
>>