Re: Shouldn't we add a new CLOSING state in H2 ?

On Sat, Jan 26, 2019, at 08:04, Patrick McManus wrote:
> 3] wait for h3 where this little tcp artifact of intentionally losing data
> is not an issue.

h3 won't solve this issue.  At least not given its current design.  That's a fundamental limitation of the design there also.  While that design corrects some of the mistakes in h2, it doesn't provide any more surety to a server about where the client is.

The shutdown design in h3 relies on the observation that only the client knows when a shutdown is complete.  The consequence being that a server never really gets told when shutdown is complete.  The client drops the connection when it has all it needs, but there is no signal to the server when this happens, other than the CONNECTION_CLOSE that the client is obligated to send.  

The assumption implicit in that design is that the only reason that a server might initiate a close is when it simply cannot continue for any reason.  The server can initiate a shutdown by sending GOAWAY, but that's all.

A server could, if it were able to, observe the stream states and look for Data Recvd/Reset Recvd on all of them, but that's not a state that stacks will necessarily expose, just as they might not expose acknowledgements.  After all, we could watch for acknowledgments of data in TCP too.

Now, the obvious question becomes: well, what if the server does want to close the connection, but clients don't reliably do that when they are sent a GOAWAY?  I don't know the answer there.  It could be that it's a largely academic question anyway, if clients are sufficiently well-behaved.

FWIW, I don't think that a GOAWAY ACK is the right concept here.  For h2, you want a clean signal that the connection is closing, because that is the action a client takes when it is done.  RFC 7540 imagines that this signal is a TCP FIN.  But we know how reliable the TCP close is, so I guess there might be room for something else.

Received on Saturday, 26 January 2019 21:44:13 UTC