Subject: [quicwg/base-drafts] TIME_WAIT (#328)

From: Patrick McManus <[email-masked]>
Date: Mon, 20 Feb 2017 09:58:00 -0800

6.4 currently has
`TODO: Connections that are terminated are added to a TIME_WAIT list at the server, so as to absorb any straggler packets in the network. Discuss TIME_WAIT list.`

this is an open issue for the TODO.

Some initial thoughts: is it always the server that is in TIME_WAIT as opposed to the TCP active close behavior? (seems fine at first blush, but asking for a friend who is less sure :)).

what happens in the TIME_WAIT state.. retransmissions? What happens when you receive packets (ignored - trigger retrrans, RST?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/328

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 20 Feb 2017 15:11:28 -0800

In the current Google QUIC implementation, for each connection in time
wait, the server saves the serialized "close" packet for that connection.
When new packets are received for that connection, the server retransmits
the close packet (subject to back-off). This is to handle the case where
the close packet is lost and so the client is unaware that the connection
has been closed. I can imagine that there might be better alternatives,
though.

On Mon, Feb 20, 2017 at 9:58 AM, Patrick McManus <[email-masked]>
wrote:

> 6.4 currently has
> TODO: Connections that are terminated are added to a TIME_WAIT list at the
> server, so as to absorb any straggler packets in the network. Discuss
> TIME_WAIT list.
>
> Some initial thoughts: is it always the server that is in TIME_WAIT as
> opposed to the TCP active close behavior? (seems fine at first blush, but
> asking for a friend who is less sure :)).
>
> what happens in the TIME_WAIT state.. retransmissions? What happens when
> you receive packets (ignored - trigger retrrans, RST?)
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/328>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ykbbcbvx3MMzki-rizoTCEy1Dh6oks5redQogaJpZM4MGeXU>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/328#issuecomment-281203095

---

From: Patrick McManus <[email-masked]>
Date: Mon, 20 Feb 2017 18:10:58 -0800

on the list @janaiyengar notes

> On the point of what to do in TIME_WAIT, the server should hang on to some
> state. At the least, hanging on to the connection ID protects the server by
> preventing late packets from causing creation of new connection state, and
> the server can simply discard incoming packets for connection IDs in
> TIME_WAIT. (If a server wanted to hang on to more state, it could do so,
> allowing it to retransmit CONNECTION_CLOSE frames later, but as you note,
> this is more state and I wouldn't require it.)

```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/328#issuecomment-281225607

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Feb 2017 11:01:41 -0800

But why is that the server specifically?  It seems like either peer, having sent a CONNECTION_CLOSE and not received one, needs to be in this state.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/328#issuecomment-282815970