RE: FIN + RST behavior

[Mike Bishop <[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.

(Note that pulling in DISINTEREST or whatever we call it would hopefully clarify this, since it removes the requirement to generate a RST_STREAM when receiving one.)

Sent from my Windows 10 phone

From: Subodh Iyengar<mailto:[e-mail]>
Sent: Wednesday, March 22, 2017 6:37 PM
To: [e-mail]<mailto:[e-mail]>
Subject: FIN + RST behavior

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