Subject: [quicwg/base-drafts] closed streams (#145)

From: Marten Seemann <[email-masked]>
Date: Thu, 12 Jan 2017 23:05:28 -0800

I added two commits regarding the closing of streams.

The current version of the draft already states that a peer that received stream data beyond the final offset (received either in STREAM frame with the FIN flag set or in a RST_STREAM frame) MUST close the connection with a QUIC_STREAM_DATA_AFTER_TERMINATION error. 
However, due to packet reordering, the packet carrying the final offset might be delayed, such that the peer first receives STREAM frames up to a certain offset, and then receives the final offset, and notices that the final offset is smaller than the offset it received before. In this case, it MUST also terminate the connection with a QUIC_STREAM_DATA_AFTER_TERMINATION error.

The second commit is concerned with what happens when a RST_STREAM is received. A common use case is the following: A client sends a POST request to a server and already begins sending data, but the Request URI doesn't accept data (e.g. there's an error 403 or 404). In those cases, the server will send a HTTP response (note that a 404 has a non-empty response body), and immediately after sending the last byte of the 404 response, it will send a RST_STREAM in order to stop the client from sending more data. In this case, QUIC needs to make sure the data sent by the server is delivered to the client (i.e. the server MUST retransmit any lost data, even after receiving the RST_STREAM response from the client), and the client MUST deliver the data received to the application, even if the packets containing the response body are delayed such that they arrive after the RST_STREAM sent by the server.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/145

-- Commit Summary --

  * handle reordered RST_STREAM frames and FIN flags
  * allow reading from streams that a RST_STREAM has been received for

-- File Changes --

    M draft-ietf-quic-transport.md (21)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/145.patch
https://github.com/quicwg/base-drafts/pull/145.diff

-- 
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/pull/145

---

From: Marten Seemann <[email-masked]>
Date: Thu, 12 Jan 2017 23:09:08 -0800

I realize there are cases where a retransmission of STREAM frames might not be necessary. In my example above only the stream data sent by the server needs to be reliably transmitted, but the stream data sent by the client is not read anyway and doesn't need retransmissions. 
Is this maybe what the TODO at the end of the section is referring to?

-- 
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/pull/145#issuecomment-272376316

---

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 15 Jan 2017 12:54:37 -0800

ghedo commented on this pull request.

> @@ -1477,16 +1474,20 @@ A final offset is present in both a frame bearing a FIN flag and in a RST_STREAM
 frame.  Upon sending either of these frames for a stream, the endpoint MUST NOT
 send a STREAM frame carrying data beyond the final offset.
 
-An endpoint that receives any frame for this stream after receiving either a FIN
-flag and all stream data preceding it, or a RST_STREAM frame, MUST quietly
-discard the frame, with one exception.  If a STREAM frame carrying data beyond
-the received final offset is received, the endpoint MUST close the connection
-with a QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
+An endpoint that receives a FIN flag or a RST_STREAM frames knows the final

"frame"

-- 
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/pull/145#pullrequestreview-16723256

---

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 15 Jan 2017 12:57:32 -0800

-An endpoint that receives any frame for this stream after receiving either a FIN
-flag and all stream data preceding it, or a RST_STREAM frame, MUST quietly
-discard the frame, with one exception.  If a STREAM frame carrying data beyond
-the received final offset is received, the endpoint MUST close the connection
-with a QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
+An endpoint that receives a FIN flag or a RST_STREAM frames knows the final
+offset for this stream. If a STREAM frame carrying data beyond the received
+final offset is received, the endpoint MUST close the connection with a
+QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
+
+An endpoint MUST close the connection with a QUIC_STREAM_DATA_AFTER_TERMINATION
+error if it receives a RST_STREAM or a FIN flag with a lower final offset than

Maybe use "RST_STREAM frame" like above?

-- 
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/pull/145#pullrequestreview-16723305

---

From: Alessandro Ghedini <[email-masked]>
Date: Sun, 15 Jan 2017 13:00:49 -0800

> @@ -1477,11 +1477,14 @@ A final offset is present in both a frame bearing a FIN flag and in a RST_STREAM

Personally (and YMMV) I find the new wording here a bit confusing, and I'd keep the previous one for this case (with your addition in the next paragraph).

-- 
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/pull/145#pullrequestreview-16723379

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jan 2017 14:02:42 -0800

@marten-seemann, I think that the first change here is non-controversial.  However, I'm concerned that the second is a fairly signficant change to the stream state machine.  Can I request that you open a new pull request for that?

-- 
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/pull/145#issuecomment-272727583

---

From: Marten Seemann <[email-masked]>
Date: Sun, 15 Jan 2017 19:24:25 -0800

@marten-seemann pushed 2 commits.

70bf032  Revert "allow reading from streams that a RST_STREAM has been received for"
080506c  minor changes, fix typos

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/145/files/782263a92e484a1d8036d39e8b2f8da716aac726..080506cd179e17a0827553667cb845a36140b545

---

From: Marten Seemann <[email-masked]>
Date: Sun, 15 Jan 2017 19:26:33 -0800

@martinthomson I reverted the controversial commit and fixed a few typos pointed out by @ghedo.

I still think that changes to the stream state machine are necessary (in one way or the other, but at the moment the behavior is not clearly defined). I'll prepare another PR for that.

-- 
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/pull/145#issuecomment-272765893

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jan 2017 19:27:45 -0800

I agree with the need for changes to the state machine, but it's a fairly big change.  We might want to consider other, more drastic changes here.

-- 
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/pull/145#issuecomment-272766013

---

From: mirjak <[email-masked]>
Date: Mon, 16 Jan 2017 02:15:04 -0800

I agree that resets and other control information should be re transmitted as quickly as possible. However, data frames could be retransmitted based on their frame priority.

-- 
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/pull/145#issuecomment-272822028

---

From: mirjak <[email-masked]>
Date: Mon, 16 Jan 2017 02:21:25 -0800

I'm not sure that if the server sends a 404 that this automatically means it must close the stream. 404 is application logic and given you received the 404 message correctly the server transport connection works. You should just close the stream regularly or even the whole connection.

-- 
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/pull/145#issuecomment-272823443

---

From: Marten Seemann <[email-masked]>
Date: Mon, 16 Jan 2017 03:20:52 -0800

@mirjak: I already reverted the corresponding commit, since there are further changes needed to handle the resetting of streams correctly. For sure, some kind of stream resetting is needed in the case of a POST to a 404 (in order to keep the flow controllers synchronized). I'll soon open a new PR for that, but I'm still figuring out the details.

-- 
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/pull/145#issuecomment-272835854

---

From: Martin Thomson <[email-masked]>
Date: Tue, 31 Jan 2017 19:36:59 -0800

martinthomson commented on this pull request.

I'm going to open a new PR for this one and I'll ask for another review, since it turned out to be a fairly big set of changes.

-An endpoint that receives any frame for this stream after receiving either a FIN
-flag and all stream data preceding it, or a RST_STREAM frame, MUST quietly
-discard the frame, with one exception.  If a STREAM frame carrying data beyond
-the received final offset is received, the endpoint MUST close the connection
-with a QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
+An endpoint that receives a FIN flag or a RST_STREAM frame knows the final
+offset for this stream. If a STREAM frame carrying data beyond the received
+final offset is received, the endpoint MUST close the connection with a
+QUIC_STREAM_DATA_AFTER_TERMINATION error ({{error-handling}}).
+
+An endpoint MUST close the connection with a QUIC_STREAM_DATA_AFTER_TERMINATION
+error if it receives a RST_STREAM frame or a FIN flag with a lower final offset
+than the highest data offset it already received on that stream.

This can be simplified greatly: 

If a STREAM frame carries data with an offset higher than the final offset, {{ERROR}}.  If a RST_STREAM or a STREAM frame marked with a FIN flag indicates a different final offset, {{ERROR}}.

-- 
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/pull/145#pullrequestreview-19476571