Re: FIN + RST behavior

[Martin Thomson <[e-mail]>]

This is just an error.  Both endpoints need to end their stream in one
way or other.  The text about not sending a RST_STREAM needs to take
into account the fact that any FIN or RST_STREAM that was previously
sent ALSO needs to be acknowledged.

A sender needs to wait for acknowledgment before transitioning to new
states.  Receivers just process and acknowledge.

I agree that this is poorly documented.  Here's the short version:

Each endpoint has to end the stream one way or other.  This
establishes the final data offset for the stream, which is necessary
for connection flow control accounting.  A stream can be ended by
either sending a STREAM frame with the FIN flag set, or a RST_STREAM
frame.  A stream isn't ended in the sending direction until a packet
containing one of those two frames has been acknowledged.  An endpoint
MAY choose to switch from sending STREAM frames to sending RST_STREAM
frames at any time.

For the long version, you will have to wait until we get around to
fixing https://github.com/quicwg/base-drafts/issues/413

On 23 March 2017 at 09:37, Subodh Iyengar <[e-mail]> wrote:
> There might be some strange cases around RSTs and FINs which I would love
> more clarity on.
>
> Let's say that the following actions happen:
> 1) Client initiates a stream to the server and sends some data
> 2) Server sends a FIN to the client which the client receives. The client
> and server are both half closed (remote and local respectively).
> 3) After some time the client sends a FIN to the server. So it's waiting for
> the FIN and the ack of all the data before closing the stream.
> 4) Server sends a RST which races with the client sending the FIN.
> 5) Client gets a RST
>
> From the draft I think it's ambiguous on what the client is supposed to do
>
> "An endpoint that receives a RST_STREAM frame (and which has not sent a FIN
> or a RST_STREAM) MUST immediately respond with a RST_STREAM frame, and MUST
> NOT send any more data on the stream"
>
> So clearly a client should not send a RST stream in response
>
> However:
> "When an endpoint sends a RST_STREAM frame, data outstanding on that stream
> SHOULD NOT be retransmitted, since subsequent data on this stream is
> expected to not be delivered by the receiver."
>
> If the client decides to honor both of these requirements I believe it will
> not retransmit the FIN. So if the FIN gets lost the client will have no idea
> whether the server has seen the FIN and reduced its
> number of streams counting towards the concurrency limit so that the client
> can open up a new stream. It would need to track the ACK of the ACK of the
> RST stream that the server sends back.
>
> Am I missing another requirement that prevents this from being an issue or
> could "not sent a FIN" mean that "not sent a FIN that has been ACKed".
>
> Subodh
>