Silent close

[martinthomson]

I think that this is one or other peer walking away from a conversation without saying goodbye. If we're going to talk about silent closes, we need to explain what it is, why a peer might choose to do it, and the consequences for everyone involved if they exist.

[martinthomson]

It's probably timely that we have the "how do you close a connection" discussion.

@janaiyengar and I were discussing one possibility. In that model, the transport only has an explicit message for error-related closes. The transport also has an idle timer that starts as soon as there are no open streams (note that this means nothing to send, nothing to receive). The connection silently closes if that timer runs down without a new stream being opened.

The application protocol could define a message that could negotiate a graceful close to trigger this. HTTP would need this, otherwise stream 3 would hold the connection open indefinitely. To speed things up, the application protocol could force the timer to be shortened to basically FIN_WAIT2 (a couple of RTOs) by telling the transport that it was done. (You need to wait around a little for retransmissions and reordering.)

[lucas-clemente]

Would PING frames reset this idle timer?

[ianswett]

@lucas-clemente PING frames reset the idle timer today in GQUIC, and that has been useful.

@martinthomson GQUIC currently closes silently by default and does close connections if there are open streams, but only after a PING has already been sent, but not acked. It's possible one can design something better, but I don't think closing the headers(or crypto) streams should be necessary.

[martinthomson]

@ianswett, I suggested closing stream 3 because otherwise the transport has no information about whether the connection is still "in use". That's a consequence of a logical separation of transport and HTTP. If we wanted to avoid that, we would need to identify "static" streams.

[gloinul]

From today's WG meeting: Martin concluded that he better understand that part of the issue is that Silent Close exists at all.

[martinthomson]

@janaiyengar, do you think that you could take lead on writing up a proposal for this? I think that you understand the TIME_WAIT/drain issues better than I do. I will talk to @MikeBishop about how we might better manage graceful shutdown for HTTP.

[janaiyengar]

We should plan to discuss this in Seattle. I'll spin up some text and slides before then so we can kick off discussion on the list.

[martinthomson]

With #721, I believe that we have the ground work in place. It's not perfect, but we should use new issues to discuss any additional changes. (There are already a couple of open issues.)