From b1c79fbd0685c05bc1c6687e07103692d637fcf9 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 18 Jan 2017 09:42:19 -0800 Subject: [PATCH 01/22] First pass at REQUEST_RST --- draft-ietf-quic-transport.md | 91 ++++++++++++++++++++++++++++-------- 1 file changed, 71 insertions(+), 20 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index aedcb5fd69..3092d110c3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -574,6 +574,7 @@ document. | 0x05 | BLOCKED | {{frame-blocked}} | | 0x06 | STOP_WAITING | {{frame-stop-waiting}} | | 0x07 | PING | {{frame-ping}} | +| 0x08 | REQUEST_RST | {{frame-request-rst}} | | 0x40 - 0x7f | ACK | {{frame-ack}} | | 0x80 - 0xff | STREAM | {{frame-stream}} | |------------------|--------------------|----------------------------| @@ -1437,10 +1438,11 @@ The BLOCKED frame contains a single field: control blocked. When zero, the Stream ID field indicates that the connection is flow control blocked. + ## RST_STREAM Frame {#frame-rst-stream} -An endpoint may use a RST_STREAM frame (type=0x01) to abruptly terminate a -stream. The frame is as follows: +An endpoint may use a RST_STREAM frame (type=0x01) to abruptly terminate +transmission on a stream. The frame is as follows: ~~~ 0 1 2 3 @@ -1467,6 +1469,31 @@ The fields are: the end of data written on this stream by the RST_STREAM sender. + + +## REQUEST_RST Frame {#frame-request-rst} + +An endpoint may use a REQUEST_RST frame (type=0x08) to request 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 terminated. + +* Error code: A 32-bit error code which indicates why the stream should be + closed. + + ## PADDING Frame {#frame-padding} The PADDING frame (type=0x00) has no semantic value. PADDING frames can be used @@ -1784,23 +1811,30 @@ A stream in the "open" state may be used by both peers to send frames of any type. In this state, a sending peer must observe the flow-control limit advertised by its receiving peer ({{flow-control}}). -From this state, either endpoint can send a frame with the FIN flag set, which -causes the stream to transition into one of the "half-closed" states. An -endpoint sending an FIN flag causes the stream state to become "half-closed -(local)". An endpoint receiving a FIN flag causes the stream state to become -"half-closed (remote)"; the receiving endpoint MUST NOT process the FIN flag -until all preceding data on the stream has been received. - -Either endpoint can send a RST_STREAM frame from this state, causing it to -transition immediately to "closed". +From this state, either endpoint can send a STREAM frame with the FIN flag set +or a RST_STREAM frame. These indicate the clean or abrupt termination of data +flow on the stream, respectively. In either case, this causes the stream to +transition into one of the "half-closed" states. An endpoint sending an FIN +flag or a RST_STREAM frame causes the stream state to become "half-closed +(local)". An endpoint receiving a FIN flag or a RST_STREAM frame causes the +stream state to become "half-closed (remote)". The receiving endpoint MUST NOT +process the FIN flag until all preceding data on the stream has been received, +but MAY process a RST_STREAM frame immediately and discard any preceding data. + +Either endpoint can send a REQUEST_RST frame in this state to request closure of +the stream in the opposite direction. This typically indicates that the +receiving application is no longer reading from the stream and all future data +will be discarded upon receipt. An endpoint SHOULD respond to a REQUEST_RST +with a RST_STREAM of type QUIC_RECEIVED_RST. ### half-closed (local) A stream that is in the "half-closed (local)" state MUST NOT be used for sending -STREAM frames; WINDOW_UPDATE and RST_STREAM MAY be sent in this state. +STREAM frames; WINDOW_UPDATE, RST_STREAM, and REQUEST_RST MAY be sent in this +state. -A stream transitions from this state to "closed" when a frame that contains an -FIN flag is received or when either peer sends a RST_STREAM frame. +A stream transitions from this state to "closed" when a STREAM frame that +contains an FIN flag or when a RST_STREAM frame is received. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. @@ -1811,6 +1845,17 @@ flow-controlled frames. In this state, a receiver MAY ignore WINDOW_UPDATE frames for this stream, which might arrive for a short period after a frame bearing the FIN flag is sent. +If an endpoint is no longer interested in the data being received in this state, +it MAY send a REQUEST_RST frame to request that the peer close the stream. +STREAM frames received after sending REQUEST_RST are still counted toward the +connection and stream flow-control windows. Even though these frames might be +ignored, because they are sent before their sender receives the REQUEST_RST, the +sender will consider the frames to count against its flow-control windows. + +If a REQUEST_RST frame is received on a stream that is already in the +"half-closed (local)" state, a RST_STREAM frame SHOULD still be sent, +so that no STREAM frames previously sent will be retransmitted. + ### half-closed (remote) A stream that is "half-closed (remote)" is no longer being used by the peer to @@ -1824,8 +1869,9 @@ A stream in this state can be used by the endpoint to send frames of any type. In this state, the endpoint continues to observe advertised stream-level and connection-level flow-control limits ({{flow-control}}). -A stream can transition from this state to "closed" by sending a frame that -contains a FIN flag or when either peer sends a RST_STREAM frame. +A stream can transition from this state to "closed" by sending a STREAM frame +that contains a FIN flag or by sending a RST_STREAM frame. Upon receipt of a +REQUEST_RST frame, a RST_STREAM frame SHOULD be sent in response. ### closed {#state-closed} @@ -2071,10 +2117,12 @@ controller. ### Response to a RST_STREAM Since streams are bidirectional, a sender of a RST_STREAM needs to know how many -bytes the peer has sent on the stream. If an endpoint receives a RST_STREAM -frame and has sent neither a FIN nor a RST_STREAM, it MUST send a RST_STREAM in -response, bearing the offset of the last byte sent on this stream as the final -offset. +bytes the peer has sent on the stream. 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 bearing the offset of the last byte sent on this stream +as the final offset, and MUST NOT send any more data on the stream. This +RST_STREAM SHOULD contain the error code QUIC_RECEIVED_RST. + ### Offset Increment @@ -2150,6 +2198,9 @@ QUIC_STREAM_CANCELLED (0x80000006): QUIC_MISSING_PAYLOAD (0x80000030): : The packet contained no payload. +QUIC_RECEIVED_RST (0x80000035): +: Terminating stream because peer sent a RST_STREAM or REQUEST_RST. + QUIC_INVALID_STREAM_DATA (0x8000002E): : STREAM frame data is malformed. From 4c96bd2a53ea421cffa51e2919f09b146edfdf86 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 18 Jan 2017 09:57:44 -0800 Subject: [PATCH 02/22] Use REQUEST_RST in HTTP/QUIC --- draft-ietf-quic-http.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index d49fbbb251..5d53395e57 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -243,11 +243,11 @@ fully closed. A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the -client abort transmission of a request without error by sending a RST_STREAM -with an error code of NO_ERROR after sending a complete response and closing its -stream. Clients MUST NOT discard responses as a result of receiving such a -RST_STREAM, though clients can always discard responses at their discretion for -other reasons. +client abort transmission of a request without error by triggering a QUIC +REQUEST_RST after sending a complete response and closing its stream. Clients +MUST NOT discard complete responses as a result of receiving a REQUEST_RST, +though clients can always discard responses at their discretion for other +reasons. ### Header Compression @@ -365,6 +365,11 @@ response, with response headers and (if present) trailers carried by HEADERS frames sent on the control stream, and response body (if any) sent via the corresponding data stream. +If a promised push stream is not needed by the client, the client SHOULD send a +QUIC REQUEST_RST on the promised stream with an appropriate error code (e.g. +HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}). This asks the +server not to transfer the data and indicates that it will be discarded upon +receipt. # HTTP Framing Layer From 7f665266b611dd166187cbf819e1243233312fa3 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 30 Jan 2017 07:05:37 -0800 Subject: [PATCH 03/22] Martin's feedback on REQUEST_RST --- draft-ietf-quic-transport.md | 75 +++++++++++++++++++----------------- 1 file changed, 40 insertions(+), 35 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3092d110c3..521830ee5a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1480,19 +1480,19 @@ 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Stream ID (32) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields are: -* Stream ID: The 32-bit Stream ID of the stream being terminated. - * Error code: A 32-bit error code which indicates why the stream should be closed. +* Stream ID: The 32-bit Stream ID of the stream being terminated. + ## PADDING Frame {#frame-padding} @@ -1816,16 +1816,10 @@ or a RST_STREAM frame. These indicate the clean or abrupt termination of data flow on the stream, respectively. In either case, this causes the stream to transition into one of the "half-closed" states. An endpoint sending an FIN flag or a RST_STREAM frame causes the stream state to become "half-closed -(local)". An endpoint receiving a FIN flag or a RST_STREAM frame causes the -stream state to become "half-closed (remote)". The receiving endpoint MUST NOT -process the FIN flag until all preceding data on the stream has been received, -but MAY process a RST_STREAM frame immediately and discard any preceding data. - -Either endpoint can send a REQUEST_RST frame in this state to request closure of -the stream in the opposite direction. This typically indicates that the -receiving application is no longer reading from the stream and all future data -will be discarded upon receipt. An endpoint SHOULD respond to a REQUEST_RST -with a RST_STREAM of type QUIC_RECEIVED_RST. +(local)". An endpoint receiving a FIN flag causes the stream state to become +"half-closed (remote)" once all preceding data on the stream has been received. +An endpoint receiving a RST_STREAM frame causes the stream state to become +"half-closed (remote)" immediately; any preceding data MAY be discarded. ### half-closed (local) @@ -1845,17 +1839,6 @@ flow-controlled frames. In this state, a receiver MAY ignore WINDOW_UPDATE frames for this stream, which might arrive for a short period after a frame bearing the FIN flag is sent. -If an endpoint is no longer interested in the data being received in this state, -it MAY send a REQUEST_RST frame to request that the peer close the stream. -STREAM frames received after sending REQUEST_RST are still counted toward the -connection and stream flow-control windows. Even though these frames might be -ignored, because they are sent before their sender receives the REQUEST_RST, the -sender will consider the frames to count against its flow-control windows. - -If a REQUEST_RST frame is received on a stream that is already in the -"half-closed (local)" state, a RST_STREAM frame SHOULD still be sent, -so that no STREAM frames previously sent will be retransmitted. - ### half-closed (remote) A stream that is "half-closed (remote)" is no longer being used by the peer to @@ -1870,8 +1853,7 @@ In this state, the endpoint continues to observe advertised stream-level and connection-level flow-control limits ({{flow-control}}). A stream can transition from this state to "closed" by sending a STREAM frame -that contains a FIN flag or by sending a RST_STREAM frame. Upon receipt of a -REQUEST_RST frame, a RST_STREAM frame SHOULD be sent in response. +that contains a FIN flag or by sending a RST_STREAM frame. ### closed {#state-closed} @@ -1915,7 +1897,26 @@ implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a connection error ({{error-handling}}). Frames of unknown types are ignored. -(TODO: QUIC_STREAM_NO_ERROR is a special case. Write it up.) + +## Solicited State Transitions + +If an endpoint is no longer interested in the data being received, it MAY send a +REQUEST_RST frame on a stream in the "open" or "half-closed (local)" state to +request closure of the stream in the opposite direction. This typically +indicates that the receiving application is no longer reading from the stream +and all future data will be discarded upon receipt. + +STREAM frames received after sending REQUEST_RST are still counted toward the +connection and stream flow-control windows. Even though these frames will be +discarded, because they are sent before their sender receives the REQUEST_RST, +the sender will consider the frames to count against its flow-control windows. + +Upon receipt of a REQUEST_RST frame, an endpoint SHOULD send a RST_STREAM with +an error code of QUIC_RECEIVED_RST. If the REQUEST_RST frame is received on a +stream that is already in the "half-closed (local)" or "closed" states, a +RST_STREAM frame SHOULD still be sent and retransmitted of previously-sent +STREAM frames SHOULD be cancelled. + ## Stream Identifiers {#stream-identifiers} @@ -2116,13 +2117,17 @@ controller. ### Response to a RST_STREAM -Since streams are bidirectional, a sender of a RST_STREAM needs to know how many -bytes the peer has sent on the stream. 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 bearing the offset of the last byte sent on this stream -as the final offset, and MUST NOT send any more data on the stream. This -RST_STREAM SHOULD contain the error code QUIC_RECEIVED_RST. - +RST_STREAM terminates a stream abruptly. Whether any action or response can +or should be taken on the data already received is an application-specific +issue. If the sender of a RST_STREAM wishes to explicitly state that no future +data will be processed, that endpoint MAY send a REQUEST_RST frame at the same +time. + +Regardless, 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. An endpoint that +receives a RST_STREAM frame MUST still close the stream for sending in the other +direction, either with a STREAM frame containing the FIN bit or a RST_STREAM +frame of its own, but MAY choose not to do so immediately. ### Offset Increment From b2dc2c2bb0c84fed5f79e5f893db8c3948e517d2 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 30 Jan 2017 07:18:45 -0800 Subject: [PATCH 04/22] Wrong word form --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 521830ee5a..58fe6c9dca 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1914,7 +1914,7 @@ the sender will consider the frames to count against its flow-control windows. Upon receipt of a REQUEST_RST frame, an endpoint SHOULD send a RST_STREAM with an error code of QUIC_RECEIVED_RST. If the REQUEST_RST frame is received on a stream that is already in the "half-closed (local)" or "closed" states, a -RST_STREAM frame SHOULD still be sent and retransmitted of previously-sent +RST_STREAM frame SHOULD still be sent and retransmission of previously-sent STREAM frames SHOULD be cancelled. From dd17d054e308fb2940bc7027c1e613f87657dfe0 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 23 Feb 2017 14:28:35 -0800 Subject: [PATCH 05/22] Fix some merge stuff --- draft-ietf-quic-transport.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 58fe6c9dca..97a146f874 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2117,17 +2117,12 @@ controller. ### Response to a RST_STREAM -RST_STREAM terminates a stream abruptly. Whether any action or response can -or should be taken on the data already received is an application-specific -issue. If the sender of a RST_STREAM wishes to explicitly state that no future -data will be processed, that endpoint MAY send a REQUEST_RST frame at the same -time. - -Regardless, 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. An endpoint that -receives a RST_STREAM frame MUST still close the stream for sending in the other -direction, either with a STREAM frame containing the FIN bit or a RST_STREAM -frame of its own, but MAY choose not to do so immediately. +RST_STREAM terminates a stream abruptly. Whether any action or response can or +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 REQUEST_RST frame at the same time. ### Offset Increment From c9d0d8fe5c53e0f7672ab67f8ba47e8ef3e8eb7a Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 7 Mar 2017 09:58:24 -0800 Subject: [PATCH 06/22] Servers shouldn't freak out either --- draft-ietf-quic-http.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 5d53395e57..a6abb33ab4 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -247,7 +247,8 @@ client abort transmission of a request without error by triggering a QUIC REQUEST_RST after sending a complete response and closing its stream. Clients MUST NOT discard complete responses as a result of receiving a REQUEST_RST, though clients can always discard responses at their discretion for other -reasons. +reasons. Servers SHOULD NOT abort a response in progress as a result of +receiving a solicited RST_STREAM. ### Header Compression From 7f0a1342e4756b82bc21f3ba8139b6057fff6598 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 7 Mar 2017 10:10:54 -0800 Subject: [PATCH 07/22] Rename to DISINTEREST --- draft-ietf-quic-http.md | 6 +++--- draft-ietf-quic-transport.md | 31 ++++++++++++++++--------------- 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index a6abb33ab4..c452cea4e2 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -244,8 +244,8 @@ A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC -REQUEST_RST after sending a complete response and closing its stream. Clients -MUST NOT discard complete responses as a result of receiving a REQUEST_RST, +DISINTEREST after sending a complete response and closing its stream. Clients +MUST NOT discard complete responses as a result of receiving a DISINTEREST, though clients can always discard responses at their discretion for other reasons. Servers SHOULD NOT abort a response in progress as a result of receiving a solicited RST_STREAM. @@ -367,7 +367,7 @@ frames sent on the control stream, and response body (if any) sent via the corresponding data stream. If a promised push stream is not needed by the client, the client SHOULD send a -QUIC REQUEST_RST on the promised stream with an appropriate error code (e.g. +QUIC DISINTEREST on the promised stream with an appropriate error code (e.g. HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}). This asks the server not to transfer the data and indicates that it will be discarded upon receipt. diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 97a146f874..856f240578 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -574,7 +574,7 @@ document. | 0x05 | BLOCKED | {{frame-blocked}} | | 0x06 | STOP_WAITING | {{frame-stop-waiting}} | | 0x07 | PING | {{frame-ping}} | -| 0x08 | REQUEST_RST | {{frame-request-rst}} | +| 0x08 | DISINTEREST | {{frame-disinterest}} | | 0x40 - 0x7f | ACK | {{frame-ack}} | | 0x80 - 0xff | STREAM | {{frame-stream}} | |------------------|--------------------|----------------------------| @@ -1471,10 +1471,11 @@ The fields are: -## REQUEST_RST Frame {#frame-request-rst} +## DISINTEREST Frame {#frame-disinterest} -An endpoint may use a REQUEST_RST frame (type=0x08) to request a peer to -abruptly terminate transmission on a stream. The frame is as follows: +An endpoint may use a DISINTEREST frame (type=0x08) 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 @@ -1488,10 +1489,10 @@ abruptly terminate transmission on a stream. The frame is as follows: The fields are: -* Error code: A 32-bit error code which indicates why the stream should be - closed. +* Error code: A 32-bit error code which indicates why the data is being + discarded. -* Stream ID: The 32-bit Stream ID of the stream being terminated. +* Stream ID: The 32-bit Stream ID of the stream being ignored. ## PADDING Frame {#frame-padding} @@ -1824,7 +1825,7 @@ An endpoint receiving a RST_STREAM frame causes the stream state to become ### half-closed (local) A stream that is in the "half-closed (local)" state MUST NOT be used for sending -STREAM frames; WINDOW_UPDATE, RST_STREAM, and REQUEST_RST MAY be sent in this +STREAM frames; WINDOW_UPDATE, RST_STREAM, and DISINTEREST MAY be sent in this state. A stream transitions from this state to "closed" when a STREAM frame that @@ -1901,18 +1902,18 @@ permitted in the description of a state as a connection error ## Solicited State Transitions If an endpoint is no longer interested in the data being received, it MAY send a -REQUEST_RST frame on a stream in the "open" or "half-closed (local)" state to +DISINTEREST frame on a stream in the "open" or "half-closed (local)" state to request closure of the stream in the opposite direction. This typically indicates that the receiving application is no longer reading from the stream and all future data will be discarded upon receipt. -STREAM frames received after sending REQUEST_RST are still counted toward the +STREAM frames received after sending DISINTEREST are still counted toward the connection and stream flow-control windows. Even though these frames will be -discarded, because they are sent before their sender receives the REQUEST_RST, +discarded, because they are sent before their sender receives the DISINTEREST, the sender will consider the frames to count against its flow-control windows. -Upon receipt of a REQUEST_RST frame, an endpoint SHOULD send a RST_STREAM with -an error code of QUIC_RECEIVED_RST. If the REQUEST_RST frame is received on a +Upon receipt of a DISINTEREST frame, 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 SHOULD still be sent and retransmission of previously-sent STREAM frames SHOULD be cancelled. @@ -2122,7 +2123,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 REQUEST_RST frame at the same time. +that endpoint MAY send a DISINTEREST frame at the same time. ### Offset Increment @@ -2199,7 +2200,7 @@ QUIC_MISSING_PAYLOAD (0x80000030): : The packet contained no payload. QUIC_RECEIVED_RST (0x80000035): -: Terminating stream because peer sent a RST_STREAM or REQUEST_RST. +: Terminating stream because peer sent a RST_STREAM or DISINTEREST. QUIC_INVALID_STREAM_DATA (0x8000002E): : STREAM frame data is malformed. From 001c274f95c10fa225a75761f38f8d59bd24b7db Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 7 Mar 2017 10:14:05 -0800 Subject: [PATCH 08/22] Suggest error code, loosen ordering --- draft-ietf-quic-http.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index c452cea4e2..6e0c31d21e 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -244,11 +244,11 @@ A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC -DISINTEREST after sending a complete response and closing its stream. Clients -MUST NOT discard complete responses as a result of receiving a DISINTEREST, -though clients can always discard responses at their discretion for other -reasons. Servers SHOULD NOT abort a response in progress as a result of -receiving a solicited RST_STREAM. +DISINTEREST with error code HTTP_EARLY_RESPONSE, sending a complete response, +and cleanly closing its streams. Clients MUST NOT discard complete responses as +a result of receiving a DISINTEREST, though clients can always discard responses +at their discretion for other reasons. Servers SHOULD NOT abort a response in +progress as a result of receiving a solicited RST_STREAM. ### Header Compression @@ -767,6 +767,10 @@ HTTP_SETTINGS_ON_WRONG_STREAM (0x0F): HTTP_MULTIPLE_SETTINGS (0x10): : More than one SETTINGS frame was received. +HTTP_EARLY_RESPONSE (0x11): +: Server is able to generate a response to the client request without selecting + the complete request body. + ## Mapping HTTP/2 Error Codes The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error From d4f77df3f9c2c78726b9599bd6b34b65adc9cdeb Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 7 Mar 2017 10:21:27 -0800 Subject: [PATCH 09/22] an => a --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 856f240578..457b71bf49 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1829,7 +1829,7 @@ STREAM frames; WINDOW_UPDATE, RST_STREAM, and DISINTEREST MAY be sent in this state. A stream transitions from this state to "closed" when a STREAM frame that -contains an FIN flag or when a RST_STREAM frame is received. +contains a FIN flag or when a RST_STREAM frame is received. An endpoint that closes a stream MUST NOT send data beyond the final offset that it has chosen, see {{state-closed}} for details. From 4ce57c568ce9abc7af842ff8f13b5c114944cee2 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 8 Mar 2017 16:10:20 -0800 Subject: [PATCH 10/22] Without selecting? --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index e5af589a1a..4e9444c426 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -784,8 +784,8 @@ HTTP_RST_CONTROL_STREAM (0x11): : A message control stream closed abruptly. HTTP_EARLY_RESPONSE (0x12): -: Server is able to generate a response to the client request without selecting - the complete request body. +: Server is able to generate a response to the client request without seeing the + complete request body. ## Mapping HTTP/2 Error Codes From df92cb1e8af7701b202f3faabb8fc7dcc0c90104 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 13 Apr 2017 15:18:05 -0700 Subject: [PATCH 11/22] Martin's less-MUSTy feedback on DISINTEREST --- draft-ietf-quic-transport.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 57e6d495c4..dbe27470da 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1764,8 +1764,6 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ @@ -2213,19 +2211,19 @@ permitted in the description of a state as a connection error 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 request closure of the stream in the opposite direction. This typically -indicates that the receiving application is no longer reading from the stream -and all future data will be discarded upon receipt. +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 connection and stream flow-control windows. Even though these frames will be discarded, because they are sent before their sender receives the DISINTEREST, the sender will consider the frames to count against its flow-control windows. -Upon receipt of a DISINTEREST frame, 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 SHOULD still be sent and retransmission of previously-sent -STREAM frames SHOULD be cancelled. +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. ## Stream Identifiers {#stream-identifiers} From 574039307697333cb8d86d7d4b62cc47a5eb9149 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 7 Jun 2017 16:28:23 +0200 Subject: [PATCH 12/22] Martin's feedback --- draft-ietf-quic-transport.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 6307e56ba4..f2905325f9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1843,9 +1843,6 @@ to abruptly terminate transmission on a stream. The frame is as follows: The fields are: -* Error code: A 32-bit error code which indicates why the data is being - discarded. - * Stream ID: The 32-bit Stream ID of the stream being ignored. @@ -2222,7 +2219,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 -RST_STREAM in this state. +DISINTEREST 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. @@ -2282,6 +2279,7 @@ Once a stream reaches this state, no frames can be sent that mention the stream. Reordering might cause frames to be received after closing, see {{state-hc-remote}}. + ## Solicited State Transitions If an endpoint is no longer interested in the data being received, it MAY send a From 52f99c7cf83c4d87c8f2ef41450a8a0343619af3 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 28 Jun 2017 10:55:53 -0700 Subject: [PATCH 13/22] Update frame type value and table --- draft-ietf-quic-transport.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 91fcfef623..067d0286e5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -884,6 +884,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}} | | 0xa0 - 0xbf | ACK | {{frame-ack}} | | 0xc0 - 0xff | STREAM | {{frame-stream}} | {: #frame-types title="Frame Types"} @@ -2034,7 +2035,7 @@ Final offset: ## DISINTEREST Frame {#frame-disinterest} -An endpoint may use a DISINTEREST frame (type=0x08) to communicate that incoming +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: From 35dfd023a707c974c4d90c51a17211bfceb8dcc7 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 27 Jul 2017 11:00:41 -0700 Subject: [PATCH 14/22] Bring back the error code --- draft-ietf-quic-transport.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e7ed9e1731..e1c88c800f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1838,12 +1838,18 @@ to abruptly terminate transmission on a stream. The frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. ## ACK Frame {#frame-ack} @@ -3143,6 +3149,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 From e0be281ea21903edc16675f958a1e33b170b8000 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 27 Jul 2017 11:03:34 -0700 Subject: [PATCH 15/22] REQUEST_RST -> DISINTEREST -> STOP_SENDING --- draft-ietf-quic-transport.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e1c88c800f..5f81d41300 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -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"} @@ -1826,11 +1826,12 @@ 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 @@ -2491,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. @@ -2554,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 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 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 +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. ## Stream Concurrency {#stream-concurrency} @@ -2745,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} @@ -2975,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): From e91b42885baa4aea55d8bd028a31d65cd9ba1421 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 27 Jul 2017 11:48:05 -0700 Subject: [PATCH 16/22] DISINTEREST->STOP_SENDING in HTTP doc --- draft-ietf-quic-http.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 10c7647574..628990d8c7 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -276,11 +276,11 @@ A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC -DISINTEREST with error code HTTP_EARLY_RESPONSE, sending a complete response, +STOP_SENDING with error code HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing its streams. Clients MUST NOT discard complete responses as -a result of receiving a DISINTEREST, though clients can always discard responses -at their discretion for other reasons. Servers SHOULD NOT abort a response in -progress as a result of receiving a solicited RST_STREAM. +a result of receiving a STOP_SENDING, though clients can always discard +responses at their discretion for other reasons. Servers SHOULD NOT abort a +response in progress as a result of receiving a solicited RST_STREAM. ### Header Compression @@ -379,7 +379,7 @@ frames sent on the control stream, and response body (if any) sent via the corresponding data stream. If a promised push stream is not needed by the client, the client SHOULD send a -QUIC DISINTEREST on the promised stream with an appropriate error code (e.g. +QUIC STOP_SENDING on the promised stream with an appropriate error code (e.g. HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}). This asks the server not to transfer the data and indicates that it will be discarded upon receipt. From 121317646f7ac70cf9ab58f88d91bcde7967af0d Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 27 Jul 2017 11:58:22 -0700 Subject: [PATCH 17/22] Clarifying stream state --- draft-ietf-quic-transport.md | 38 +++++++++++++++--------------------- 1 file changed, 16 insertions(+), 22 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5f81d41300..d5997608b4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2470,16 +2470,15 @@ but loss or reordering can cause packets that open streams to arrive out of order. From the "open" state, either endpoint can send a frame with the FIN flag set, -which causes the stream to transition into one of the "half-closed" states. -This flag can be set on the frame that opens the stream, which causes the stream -to immediately become "half-closed". Once an endpoint has completed sending all +which causes the stream to transition into one of the "half-closed" states. This +flag can be set on the frame that opens the stream, which causes the stream to +immediately become "half-closed". Once an endpoint has completed sending all stream data and a STREAM frame with a FIN flag, the stream state becomes -"half-closed (local)". When an endpoint receives all stream data a FIN flag the -stream state becomes "half-closed (remote)". An endpoint MUST NOT consider the -stream state to have changed until all data has been sent, received or -discarded. +"half-closed (local)". When an endpoint receives all stream data and a FIN flag +the stream state becomes "half-closed (remote)". An endpoint MUST NOT consider +the stream state to have changed until all data has been sent or received. -A RST_STREAM frame on an "open" stream causes the stream to become +A RST_STREAM frame on an "open" stream also causes the stream to become "half-closed". A stream that becomes "open" as a result of sending or receiving RST_STREAM immediately becomes "half-closed". Sending a RST_STREAM frame causes the stream to become "half-closed (local)"; receiving RST_STREAM causes the @@ -2518,10 +2517,6 @@ received data. Once all data has been either received or discarded, a sender is no longer obligated to update the maximum received data for the connection. -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. - Due to reordering, an endpoint could continue receiving frames for the stream even after the stream is closed for sending. Frames received after a peer closes a stream SHOULD be discarded. An endpoint MAY choose to limit the period @@ -2536,11 +2531,10 @@ mentions a stream ID. In this state, the endpoint MUST observe advertised stream and connection data limits (see {{flow-control}}). A stream transitions from this state to "closed" by completing transmission of -all data. This includes sending all data carried in STREAM frames up including -the terminal STREAM frame that contains a FIN flag. +all data. This includes sending all data carried in STREAM frames up to and +including the terminal STREAM frame that contains a FIN flag. -A stream becomes "closed" when the endpoint sends and receives acknowledgment of -a RST_STREAM frame. +A stream also becomes "closed" when the endpoint sends a RST_STREAM frame. ### closed {#state-closed} @@ -2741,12 +2735,12 @@ controller. ### Response to a RST_STREAM -RST_STREAM terminates a stream abruptly. Whether any action or response can or -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 STOP_SENDING frame at the same time. +RST_STREAM terminates one direction of a stream abruptly. Whether any action or +response can or 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 STOP_SENDING frame at the same time. ### Data Limit Increments {#fc-credit} From 23c7dd2953dabff330c1ed391f3f4b2c193d4cf1 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 27 Jul 2017 13:48:48 -0700 Subject: [PATCH 18/22] delete 'up to and' --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d5997608b4..1e33e8352c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2531,8 +2531,8 @@ mentions a stream ID. In this state, the endpoint MUST observe advertised stream and connection data limits (see {{flow-control}}). A stream transitions from this state to "closed" by completing transmission of -all data. This includes sending all data carried in STREAM frames up to and -including the terminal STREAM frame that contains a FIN flag. +all data. This includes sending all data carried in STREAM frames including +the terminal STREAM frame that contains a FIN flag. A stream also becomes "closed" when the endpoint sends a RST_STREAM frame. From 7a46965980fead43cb964f27e5183e8014c941b5 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 31 Jul 2017 11:00:38 -0700 Subject: [PATCH 19/22] STOP_SENDING in half-closed remote --- draft-ietf-quic-transport.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1e33e8352c..ab463c2c71 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2559,11 +2559,12 @@ connection and stream flow-control windows. Even though these frames will be 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 STOP_SENDING 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 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. +Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed +(remote)" states, an 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. ## Stream Concurrency {#stream-concurrency} From 5699b82e4ce61cd90754038f0652568ecb625edb Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 31 Jul 2017 13:16:52 -0700 Subject: [PATCH 20/22] Remove implied ordering of STOP_SENDING and STREAM frames --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ab463c2c71..fa63c3567c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2555,9 +2555,9 @@ 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 STOP_SENDING are still counted toward the -connection and stream flow-control windows. Even though these frames will be -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. +connection and stream flow-control windows, even though these frames will be +discarded upon receipt. This avoids potential ambiguity about which STREAM +frames count toward flow control. Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed (remote)" states, an endpoint SHOULD send a RST_STREAM with an error code of From 106c1655fa89fe907da843fddbee5e8c0c85682d Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 1 Aug 2017 11:06:52 -0700 Subject: [PATCH 21/22] STOP_SENDING is sorta retransmittable and MUSTy --- draft-ietf-quic-transport.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fa63c3567c..2b428ad710 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2277,7 +2277,10 @@ When a packet is detected as lost, the sender re-sends any frames as necessary: receiver. * ACK and PADDING frames MUST NOT be retransmitted. ACK frames - containing updated information will be sent as described in {{frame-ack}}. + containing updated information will be sent as described in {{frame-ack}}. + +* STOP_SENDING frames MUST be retransmitted, unless the stream has become closed + in the appropriate direction. See {{solicited-state-transitions}}. * All other frames MUST be retransmitted. @@ -2560,12 +2563,17 @@ discarded upon receipt. This avoids potential ambiguity about which STREAM frames count toward flow control. Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed -(remote)" states, an endpoint SHOULD send a RST_STREAM with an error code of +(remote)" states, an endpoint MUST 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. +While STOP_SENDING frames are retransmittable, an implementation MAY choose not +to retransmit a lost STOP_SENDING frame if the stream has already been closed +in the appropriate direction since the frame was first generated. +See {{packetization}}. + ## Stream Concurrency {#stream-concurrency} From 0b027f360213d4b99483fa8773c03307c51d349e Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Wed, 2 Aug 2017 10:32:22 -0700 Subject: [PATCH 22/22] Jana's nits --- draft-ietf-quic-http.md | 6 +++--- draft-ietf-quic-transport.md | 5 ++--- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 628990d8c7..117a692918 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -278,9 +278,9 @@ not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by triggering a QUIC STOP_SENDING with error code HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing its streams. Clients MUST NOT discard complete responses as -a result of receiving a STOP_SENDING, though clients can always discard -responses at their discretion for other reasons. Servers SHOULD NOT abort a -response in progress as a result of receiving a solicited RST_STREAM. +a result of having their request terminated abruptly, though clients can always +discard responses at their discretion for other reasons. Servers MUST NOT +abort a response in progress as a result of receiving a solicited RST_STREAM. ### Header Compression diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 2b428ad710..485ac6a890 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1849,8 +1849,7 @@ 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. +: The application-specified reason the sender is ignoring the stream. ## ACK Frame {#frame-ack} @@ -2553,7 +2552,7 @@ Reordering might cause frames to be received after closing, see If an endpoint is no longer interested in the data being received, it MAY send a 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 +prompt closure of the stream in the opposite direction. This typically indicates that the receiving application is no longer reading from the stream, but is not a guarantee that incoming data will be ignored.