Re: FIN + RST behavior

[Subodh Iyengar <[e-mail]>]

@Mike Bishop<mailto:[e-mail]>
> I don’t see these as in conflict.  If the client receives a RST when it has already sent a FIN, it's not subject to the MUST.  It may, of course, opt to send a RST and abort retransmission.  Or, it may choose to just let the sent data be, but with the obligation to retransmit it.  Its obligation is to deliver the final offset, and all data up to that offset if the offset is in a FIN.

To confirm that I'm interpreting you correctly I'm going to try and rephrase that a bit: The intent of the draft is that if the client receives the RST stream and it has already sent a FIN, it should ignore the RST, and perform retransmission of all the packets as it usually would, even if the server is no longer interested in it. If it wanted to not retransmit the packets, it should send a RST of it's own.

@Martin Thomson<mailto:[e-mail]>
>  A sender needs to wait for acknowledgment before transitioning to new
states.  Receivers just process and acknowledge.
Ya that's definitely a given. The issue here I was asking about was what if there would never be an ACK for the FIN because the client decided to abort the retransmissions.

>  Both endpoints need to end their stream in one
way or other.
That's definitely true but it seems like closing a stream which is not initiated by you has a different behavior with respect to closing streams initiated by you because you need to account for
stream concurrency limit and connection flow control window differently.

> Here's the short version:
Ya this is definitely a very simplistic description of what needs to be done when a connection needs to be closed and doesn't account for how to keep the client + server in sync for the concurrency limit
and connection flow control window which is also very important. My question was actually about the latter.

This stuff gets hairy fast.

For example in a clean close:
1) client sends FIN to server, sever gets FIN
2) Server sends ACK for the client's FIN (client is now half closed local)
2) server sends data and FIN (Server doesn't change state, it waits for the ACK of all the bytes + FIN)
3) client gets all data and FIN and then ACKs all of it.
4) the client ACK for the server FIN gets lost

>From the client's perspective it sent out all the ACKs for the FIN and doesn't know whether they got lost.
How does the client know when the server has released a slot in it's concurrency limit? The server can't immediately release this when it sends out the FIN because it still must keep state until it receives all the
ACKs for the stream. I think the client need to keep track of the ACK of the ACKs of all the server sent bytes in the stream, which would be a bit sad.

Subodh


________________________________
From: Martin Thomson <[e-mail]>
Sent: Wednesday, March 22, 2017 5:45:31 PM
To: Subodh Iyengar
Cc: [e-mail]
Subject: Re: FIN + RST behavior

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
>