Subject: [quicwg/base-drafts] Is it permitted to send both FIN and RST (#779)

From: ekr <[email-masked]>
Date: Tue, 19 Sep 2017 04:50:36 -0700

@mcmanus argues that this is useful because you might send FIN and then get tired of waiting for ACKs and that it's processed on the receiver side where first one that comes ready (RST received, FIN in-order) is processed and the other ignored. My reading of the text is that this is implicitly allowed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779

---

From: ekr <[email-masked]>
Date: Tue, 19 Sep 2017 04:54:08 -0700

@mikkelfj argues that this violates the state machine because there's no outgoing arc from half-closed (local) for RST and the text implies that the state machine is canonical: 

```
   In the absence of more specific guidance elsewhere in this document,
   implementations SHOULD treat the receipt of a frame that is not
   expressly permitted in the description of a state as a connection
   error (see Section 12).
```

At minimum, the state machine and text need to be annotated to make clear that the half-closed (remote) transition happens when FIN is in-order.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330515736

---

From: ianswett <[email-masked]>
Date: Tue, 19 Sep 2017 05:48:00 -0700

My mental model is that you should send exactly one of them, but I admit there are use cases(ie: WebRTC, sub-CWND http responses) where one could send a FIN and then decide there was no need to retransmit any of the data, hence need to send a reset.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330528088

---

From: MikkelFJ <[email-masked]>
Date: Tue, 19 Sep 2017 12:56:08 +0000 (UTC)

Another point to consider: if permitting sending both RST and FIN the peer state is unpredictable: if sending only RST you KNOW the stream is not consumed. If only sending FIN you KNOW the stream is consumed eventually unless the connection fails. For example HTTP might show content up to RST, but a REST API might cancel unless receiving FIN. The REST API sender can be sure that receiver will not accept the request upon RST, but if FIN was followed by RST it would be ambigous.

This also relates to partial reliability and when to abandon old frames, but I thinkt that is a separate concern.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330530112

---

From: janaiyengar <[email-masked]>
Date: Tue, 19 Sep 2017 19:43:12 +0000 (UTC)

Allowing this seems completely reasonable to me. I'll take a crack at some edits.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330651865

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 Sep 2017 09:33:21 -0700

Let's not forget that RST and FIN are supposed to be only initiated by the application. What does that mean for an application to issue RST after FIN?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330908566

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 20 Sep 2017 09:49:17 -0700

Consider the case of an HTTP client which has completely sent the request,
and is waiting for the response from the server. While it is waiting, the
user navigates away from the page and so the client wants to cancel the
transaction.

On Wed, Sep 20, 2017 at 9:33 AM, Christian Huitema <[email-masked]
> wrote:

> Let's not forget that RST and FIN are supposed to be only initiated by the
> application. What does that mean for an application to issue RST after FIN?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/779#issuecomment-330908566>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ypffdl05DbnPuqD-Aavtb9nci3tRks5skT5RgaJpZM4PcRW0>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-330912738

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Sep 2017 22:38:32 +0000 (UTC)

@mikkelfj, I'm not sure that's true.  The structure of an HTTP/QUIC request is defined in terms of frames within the stream.  If you've successfully received all frames that constitute a request message, then the stream gets RST, I think you're in a bit of a gray area.  Implementations are naturally going to start consuming requests as they arrive to deal with large requests that have to be streamed, so you can't just ignore a request until the stream FINs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-331301153

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Sep 2017 22:39:39 +0000 (UTC)

@huitema, FIN means the application has completed everything it was going to write.  RST means it now realizes it didn't need to write what it already has.  That realization can reasonably arrive after dumping the data in the send buffer.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-331301354

---

From: MikkelFJ <[email-masked]>
Date: Thu, 21 Sep 2017 23:16:12 +0000 (UTC)

@MikeBishop I'm not familiar with QUIC/HTTP protocol details, but http display processing is different from REST API processing where receving a JSON document in a HTTP post operation is likely. Here it is all or nothing. Now, JSON is naturally bracketed so last bracket indicages the end, but you could have an arbitrary line based format where there is no natural end, other than CRLF CRLF or connection close in traditional HTTP bodies (not that this is very reliable). At any rate, it was merely an example, as QUIC can be used for more than HTTP. I.e. the point is, sometimes you need to know if you received all, and FIN is that something. But, since connections can fail, it might not matter much if the stream is RST after FIN, or the connection globally breaks for one reason or another. Thus, API's need other means to ensure transactional integrity regardless (most just hope for the best).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-331307170

---

From: MikkelFJ <[email-masked]>
Date: Thu, 21 Sep 2017 23:34:22 +0000 (UTC)

Receiving RST after FIN complicates transport to application signalling in the receiver because QUIC cannot optimistically signal that at got FIN at a given offset so, e.g. application can go ahead and reserve resources in anticipation of inbound data. It might be simpler for the sender to send all data except for FIN until it is certain that the data is relevant, or send RST instead. This could lead to extra frames, or not, depending on timing, but if could also make sense to send data ahead of time and withhold FIN for quite a while (say waiting for other operations to succeed), and then an extra frame for FIN makes perfect sense - leading to low overhead finalization for the stream.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/779#issuecomment-331309913