Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Independent states and STOP_SENDING #171

Merged
merged 29 commits into from
Aug 3, 2017
Merged

Independent states and STOP_SENDING #171

Changes from 2 commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
b1c79fb
First pass at REQUEST_RST
MikeBishop Jan 18, 2017
4c96bd2
Use REQUEST_RST in HTTP/QUIC
MikeBishop Jan 18, 2017
7f66526
Martin's feedback on REQUEST_RST
MikeBishop Jan 30, 2017
b2dc2c2
Wrong word form
MikeBishop Jan 30, 2017
dd17d05
Fix some merge stuff
MikeBishop Feb 23, 2017
c9d0d8f
Servers shouldn't freak out either
MikeBishop Mar 7, 2017
7f0a134
Rename to DISINTEREST
MikeBishop Mar 7, 2017
001c274
Suggest error code, loosen ordering
MikeBishop Mar 7, 2017
d4f77df
an => a
MikeBishop Mar 7, 2017
dccd3f3
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Mar 9, 2017
4ce57c5
Without selecting?
MikeBishop Mar 9, 2017
5088ec5
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Apr 13, 2017
df92cb1
Martin's less-MUSTy feedback on DISINTEREST
MikeBishop Apr 13, 2017
3ac8550
Merging with Martin's stream state text
MikeBishop May 2, 2017
5740393
Martin's feedback
MikeBishop Jun 7, 2017
299e72d
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Jun 7, 2017
1536501
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Jun 28, 2017
52f99c7
Update frame type value and table
MikeBishop Jun 28, 2017
15da4ce
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Jul 24, 2017
35dfd02
Bring back the error code
MikeBishop Jul 27, 2017
e0be281
REQUEST_RST -> DISINTEREST -> STOP_SENDING
MikeBishop Jul 27, 2017
e91b428
DISINTEREST->STOP_SENDING in HTTP doc
MikeBishop Jul 27, 2017
1213176
Clarifying stream state
MikeBishop Jul 27, 2017
23c7dd2
delete 'up to and'
MikeBishop Jul 27, 2017
7a46965
STOP_SENDING in half-closed remote
MikeBishop Jul 31, 2017
5699b82
Remove implied ordering of STOP_SENDING and STREAM frames
MikeBishop Jul 31, 2017
106c165
STOP_SENDING is sorta retransmittable and MUSTy
MikeBishop Aug 1, 2017
0b027f3
Jana's nits
MikeBishop Aug 2, 2017
53d1621
Merge remote-tracking branch 'origin/master' into request_rst
MikeBishop Aug 2, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 28 additions & 17 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -886,7 +886,7 @@ explained in more detail as they are referenced later in the document.
| 0x09 | STREAM_BLOCKED | {{frame-stream-blocked}} |
| 0x0a | STREAM_ID_NEEDED | {{frame-stream-id-needed}} |
| 0x0b | NEW_CONNECTION_ID | {{frame-new-connection-id}} |
| 0x0c | DISINTEREST | {{frame-disinterest}} |
| 0x0c | STOP_SENDING | {{frame-stop-sending}} |
| 0xa0 - 0xbf | ACK | {{frame-ack}} |
| 0xc0 - 0xff | STREAM | {{frame-stream}} |
{: #frame-types title="Frame Types"}
Expand Down Expand Up @@ -1826,24 +1826,31 @@ Connection ID:

: A 64-bit connection ID.

## DISINTEREST Frame {#frame-disinterest}
## STOP_SENDING Frame {#frame-stop-sending}

An endpoint may use a DISINTEREST frame (type=0x0c) to communicate that incoming
data is being discarded on receipt at application request. This signals a peer
to abruptly terminate transmission on a stream. The frame is as follows:
An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate that
incoming data is being discarded on receipt at application request. This
signals a peer to abruptly terminate transmission on a stream. The frame is as
follows:

~~~
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~

The fields are:

* Stream ID: The 32-bit Stream ID of the stream being ignored.
Stream ID:
: The 32-bit Stream ID of the stream being ignored.

Error Code:
: The reason the sender is ignoring the stream, or QUIC_NO_ERROR if not due to
an error.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this always an application error code and never a QUIC one? If so, can we simply say this is for the application to specify and consume, as one of the app-specified error codes? I don't think you need a QUIC_NO_ERROR in this case.


## ACK Frame {#frame-ack}

Expand Down Expand Up @@ -2485,7 +2492,7 @@ Any frame type that mentions a stream ID can be sent in this state.
A stream that is in the "half-closed (local)" state MUST NOT be used for sending
on new STREAM frames. Retransmission of data that has already been sent on
STREAM frames is permitted. An endpoint MAY also send MAX_STREAM_DATA and
DISINTEREST in this state.
STOP_SENDING in this state.

An endpoint that closes a stream MUST NOT send data beyond the final offset that
it has chosen, see {{state-closed}} for details.
Expand Down Expand Up @@ -2548,21 +2555,21 @@ Reordering might cause frames to be received after closing, see
## Solicited State Transitions

If an endpoint is no longer interested in the data being received, it MAY send a
DISINTEREST frame on a stream in the "open" or "half-closed (local)" state to
STOP_SENDING frame on a stream in the "open" or "half-closed (local)" state to
request closure of the stream in the opposite direction. This typically
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorial nit: does it make sense to say "request", since it's more of a "demand"? I can't come up with better wording, but maybe "require"? Up to you.

indicates that the receiving application is no longer reading from the stream,
but is not a guarantee that incoming data will be ignored.

STREAM frames received after sending DISINTEREST are still counted toward the
STREAM frames received after sending STOP_SENDING are still counted toward the
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a sender of STOP WAITING can technically detect that a sender sent data after it got the stop waiting, should it error the connection in that case?

I might have missed a MUST behavior associated with STOP_WAITING. Is it still a recommendation and not a required behavior?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommendation. STOP_SENDING is advisory that your data is being discarded and is pointless, but doesn't force a transition. (The SHOULD is at the paragraph where your next comment was located.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a requirement now, right? I don't think we need to specify enforcement though... that seems like a bit of an overkill. Besides a sender of STOP_SENDING will have to make assumptions about how the peer's sending code is structured to make an assessment of when to consider the peer in error. For instance, the peer may have buffered data that gets drained after the received STOP_SENDING is acked... surely not a good way to write that code, but there's no reason to require this not happen.

connection and stream flow-control windows. Even though these frames will be
discarded, because they are sent before their sender receives the DISINTEREST,
discarded, because they are sent before their sender receives the STOP_SENDING,
the sender will consider the frames to count against its flow-control windows.

Upon receipt of a DISINTEREST frame on a stream in the "open" state, an endpoint
SHOULD send a RST_STREAM with an error code of QUIC_RECEIVED_RST. If the
DISINTEREST frame is received on a stream that is already in the "half-closed
(local)" or "closed" states, a RST_STREAM frame MAY still be sent in order to
cancel retransmission of previously-sent STREAM frames.
Upon receipt of a STOP_SENDING frame on a stream in the "open" state, an
Copy link

@siyengar siyengar Jul 31, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason this requirement is only in open state and not in half-closed remote as well?

This whole paragraph seems strangely worded, it just basically says, "Hey you can send a RST stream in response to a STOP_SENDING" any time. Does it add a lot of value to make QUIC_RECEIVED_RST a special case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point on hc-remote -- I'll update that. The point of the paragraph is that if you're currently transmitting data, you SHOULD cut it off. If you're done transmitting data, but you might still have retransmissions going, you MAY reset the stream or just finish your retransmissions as normal, whichever is easier.

The QUIC_RECEIVED_RST error code is there to make it easier to distinguish RST-because-error from RST-because-you-said-to.

endpoint SHOULD send a RST_STREAM with an error code of QUIC_RECEIVED_RST. If
the STOP_SENDING frame is received on a stream that is already in the
"half-closed (local)" or "closed" states, a RST_STREAM frame MAY still be sent
in order to cancel retransmission of previously-sent STREAM frames.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wording seems a bit strange to me. Why does sending a RST_STREAM frame cancel retransmission of STREAM frames, isn't canceling retransmission a decision made by the sender locally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of. The spec says that a stream isn't closed until you've successfully delivered all STREAM frames up through the FIN flag; that means you have to keep retransmitting until everything gets through to close a stream that way. However, if the recipient is actually ignoring your data anyway, it's not clear how tightly they'll hold you to that.

For state machine consistency, if you're not retransmitting data, you're supposed to (reliably) send a RST_STREAM to indicate that.



## Stream Concurrency {#stream-concurrency}
Expand Down Expand Up @@ -2739,7 +2746,7 @@ should be taken on the data already received is an application-specific issue,
but it will often be the case that upon receipt of a RST_STREAM an endpoint
will choose to stop sending data in its own direction. If the sender of a
RST_STREAM wishes to explicitly state that no future data will be processed,
that endpoint MAY send a DISINTEREST frame at the same time.
that endpoint MAY send a STOP_SENDING frame at the same time.

### Data Limit Increments {#fc-credit}

Expand Down Expand Up @@ -2969,7 +2976,7 @@ PROTOCOL_VIOLATION (0x8000000A):

QUIC_RECEIVED_RST (0x80000035):

: Terminating stream because peer sent a RST_STREAM or DISINTEREST.
: Terminating stream because peer sent a RST_STREAM or STOP_SENDING.

FRAME_ERROR (0x800001XX):

Expand Down Expand Up @@ -3143,6 +3150,10 @@ thanks to all.

Issue and pull request numbers are listed with a leading octothorp.

## Since draft-ietf-quic-transport-04

- Introduce STOP_SENDING frame (#165)

## Since draft-ietf-quic-transport-03

- Change STREAM and RST_STREAM layout
Expand Down