Re: Closing on CONNECTION_CLOSE

[Willy Tarreau <[e-mail]>]

On Thu, Jul 27, 2017 at 02:08:33PM +0000, Subodh Iyengar wrote:
> I favor the RST model as well.
> You'll end up having to keep a loss timeout even in the FIN model because
> of ACKs being lost / the remote side shutting for unrelated reasons / silently closing
> their connection.

I prefer the RST model as well in general, but it's important to keep in
mind that it doesn't apply perfectly everywhere. In TCP, when the receiver
is waiting for data and has nothing to say and the sender suddenly sends
an RST which is lost, the sender definitely closes and the receiver stays
open forever. This is even more visible through firewalls because if the
RST is lost between the firewall and the receiver, the firewall will quickly
close its session and any receiver's packets will then be blocked. The usual
case is when a client/proxy has to close an idle connection going to a server
and cannot use the regular FIN model for TIME_WAIT accumulation reasons. In
this case using massive RSTs occasionally exhibits zombie connections on the
server.

I don't think it would be an issue with QUIC since the use cases are very
dynamic connections where timeouts could be expected to be reasonably low
(ie no need to have multi-days timeouts there as is sometimes done with
SSH connections).

> As an aside on the topic of TIME_WAIT itself:
> 
> The reason I'm aware that TIME_WAIT exists in TCP is to protect us from the local port
> being re-bound to another connection and the data from the old connection interfering with
> the new connection. With QUIC this seems less of an issue though because a
> combination of (connection id + packet type + packet encryption) can be used to determine whether or
> not the packet was valid to be received in the context of a new connection. Going with the
> philosophy of dropping packets on the floor that are malformed that martin proposed during
> the last WG meeting, do we even need a TIME_WAIT state in QUIC?

Agreed, TIME_WAIT is a protection against fast reuse of a scarce resource
which could cause confusion (source ports, sequence numbers). If we have
no risk of accidently mixing up connections, better get rid of it.

Willy