Connections SHOULD Respond to Connection Close Frames

[nibanks]

The spec currently says the following:

After receiving a closing frame, endpoints enter the draining state.
An endpoint that receives a closing frame MAY send a single packet
containing a closing frame before entering the draining state, using
a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate. An
endpoint MUST NOT send further packets, which could result in a
constant exchange of closing frames until the closing period on
either peer ended.

I'd like to make a case for changing that MAY to a SHOULD.

If we are recommending that the sender of the initial CONNECTION_CLOSE wait the closing/draining period, why not recommend the receiver try to always respond to its frame with a CONNECTION_CLOSE of its own? Assuming it then obeys the rule about not sending any other packets, when (if) the initial closer receives the corresponding close frame, it now know that it shouldn't be receiving any other packets (other than possible reordered packets).

In response to receiving the close response, the initial closer can then chose to either continue waiting the draining period to handle reordered packets or just immediately cleanup.

[martinduke]

This seems like the case where CONNECTION_CLOSEs pass each other in flight, so there shouldn't be much of an issue. It certainly seems much easier to debug, and can let closers tear down faster.

I am somewhat suspicious that in the real world busy servers will just teardown in DRAIN immediately. If an OOO packet generates a stateless reset, that's probably cheaper than holding on to some state for a while.

[nibanks]

I am not referring to the case where CONNECTIO_CLOSEs pass each other in flight. I am specifically thinking about the scenario where one side starts the connection close process. I think it is worthwhile for the other side to generally acknowledge the CONNECTION_CLOSE frame with one of its own. I agree there might be cases, such as a server under heavy load, where that might not happen, but I believe it should most of the time.

[ianswett]

At the point the CONNECTION_CLOSE has been sent, the connection is essentially over. Having the peer respond with a CONNECTION_CLOSE/no error would allow the sender of the packet containing the CONNECTION_CLOSE to no longer store it in memory, but I believe it has no other effect, so this seems like a case of trading off an extra packet to send/receive with a small amount of buffered memory.

But in order to process an encrypted packet, you have to store more connection state than just a connection ID and the final connection close packet, so if peers didn't send back connection closes and you expected them, there would be a slight increase in memory usage.

So I'd prefer to stick with MAY, since as a server, I expect I'll continue to not process incoming packets from closed connections, so they'd just be wasted packets.

[nibanks]

What about when the client is closing the connection? It shouldn't be nearly as big a deal for clients to keep additional state around waiting for the server's response?

[ianswett]

Agreed. In practice, I expect a lot of HTTP/QUIC clients to destroy all state after sending a connection close, so they wouldn't store anything. But it likely depends upon the application.

[marten-seemann]

@ianswett: Are you saying that you expect that many (most? all?) client and server implementations will not adhere to the spec regarding the drain periods? I see the point, since at the moment when a connection is over, there's no point in being a nice and spec-compliant peer any more.
If we think this is actually the case, I'm beginning to wonder what the whole point of specifying the drain period is.

[martinthomson]

Clients that drop sockets won't necessarily respect this, but servers will have to.

[ianswett]

I agree with Martin, I think client behavior will vary and many will immediately close the socket. I expect servers to adhere.

[nibanks]

I guess the main point I had here was, if an endpoint (client or server) is going to stick around for the draining period, shouldn't it respond to the initially received CONNECTION_CLOSE frame with its own?

[ianswett]

I would say no.

[nibanks]

If not, then implementations that wish to respect the spec will always have to wait the full draining period. What is the harm in recommending the CONNECTION_CLOSE should be sent? It is a very useful signal to the endpoint that initially closed the connection.

[ianswett]

I think we've come back around to our comments from a day ago. I suspect most implementations will ignore it, and you think it's very useful. I suggest we stick with MAY for now and we can discuss this again in 6 months when hopefully more people have implementation experience.

If specific applications want to specify MUST, that's fine by me, but I don't think it makes sense for HTTP.

[martinthomson]

In practice, the closing side will be dropping packets. Having implemented this, it's quite hard to consume the closing frame. I don't think that we gain anything from encouraging this. You can do what you think you need to, but I'm not seeing anyone else pushing for this. The editors are agreed that MAY is entirely appropriate.