From c0198331387dc3e7705fe2992cd266d71588c161 Mon Sep 17 00:00:00 2001 From: martinduke Date: Fri, 19 Oct 2018 10:29:52 -0700 Subject: [PATCH 1/5] Explicitly suggest FIN or RST_STREAM For issue #1878. I was apparently the only one confused, but since this is different from HTTP/2 it may be good to make it crystal clear. --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 145bb7ca53..ba03cab5d1 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -803,12 +803,13 @@ frame, and the receiver MUST use the final offset to account for all bytes sent on the stream in its connection level flow controller. 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. - +response can or should be taken on the data already received is an application- +specific issue. It will often be the case that upon receipt of a RST_STREAM on a +bidirectional stream, an endpoint will choose to stop sending data to the peer +on that stream. In this case, it SHOULD send a FIN or RST_STREAM for that +stream to close the peer's receive stream state. 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 e6d9bbec399e08b5c1ca33b518fb8f25bc79ee61 Mon Sep 17 00:00:00 2001 From: martinduke Date: Fri, 19 Oct 2018 11:17:26 -0700 Subject: [PATCH 2/5] mikkelfj's comments --- draft-ietf-quic-transport.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ba03cab5d1..11a1f11a4c 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -806,10 +806,11 @@ 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. It will often be the case that upon receipt of a RST_STREAM on a bidirectional stream, an endpoint will choose to stop sending data to the peer -on that stream. In this case, it SHOULD send a FIN or RST_STREAM for that -stream to close the peer's receive stream state. 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. +on that stream. If so, it SHOULD send a FIN or RST_STREAM for that stream to +close the peer's receive stream state. Alternatively an endpoint can choose to +continue 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 1b8a9c6000f94c1eadcdfff535e4146fff80b39c Mon Sep 17 00:00:00 2001 From: martinduke Date: Fri, 19 Oct 2018 15:58:57 -0700 Subject: [PATCH 3/5] Fix line that was too long --- 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 11a1f11a4c..e474f72af5 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -809,8 +809,8 @@ bidirectional stream, an endpoint will choose to stop sending data to the peer on that stream. If so, it SHOULD send a FIN or RST_STREAM for that stream to close the peer's receive stream state. Alternatively an endpoint can choose to continue 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. +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 755e32942b9db5d45ab08600171dbf9dde41ced7 Mon Sep 17 00:00:00 2001 From: martinduke Date: Sat, 20 Oct 2018 20:33:42 -0700 Subject: [PATCH 4/5] Rewrote to address discussion The reviews expired a rewrite. I think it's even clearer now, and avoids some of the bad inferences of the previous version. --- draft-ietf-quic-transport.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e474f72af5..5da8e32121 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -804,13 +804,13 @@ on the stream in its connection level flow controller. 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. It will often be the case that upon receipt of a RST_STREAM on a -bidirectional stream, an endpoint will choose to stop sending data to the peer -on that stream. If so, it SHOULD send a FIN or RST_STREAM for that stream to -close the peer's receive stream state. Alternatively an endpoint can choose to -continue 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. +specific issue. + +For a bidirectional stream, RST_STREAM has no effect on data flow in the +opposite direction. Both endpoints MUST maintain state for that direction until +that direction enters a terminal state, or either side sends CONNECTION_CLOSE or +APP_CLOSE. The RST_STREAM sender MAY also send a STOP_SENDING frame to encourage +prompt termination. ## Data Limit Increments {#fc-credit} From 13945f96c4f7b063e92c989707f75f4adee85d7e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 22 Oct 2018 09:55:09 +1100 Subject: [PATCH 5/5] Tweak it --- draft-ietf-quic-transport.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5da8e32121..c9bba3dbf7 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -803,14 +803,14 @@ frame, and the receiver MUST use the final offset to account for all bytes sent on the stream in its connection level flow controller. 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. +response can or should be taken on the data already received is application +specific. For a bidirectional stream, RST_STREAM has no effect on data flow in the -opposite direction. Both endpoints MUST maintain state for that direction until -that direction enters a terminal state, or either side sends CONNECTION_CLOSE or -APP_CLOSE. The RST_STREAM sender MAY also send a STOP_SENDING frame to encourage -prompt termination. +opposite direction. The RST_STREAM sender can send a STOP_SENDING frame to +encourage prompt termination. Both endpoints MUST maintain state for the stream +in the unterminated direction until that direction enters a terminal state, or +either side sends CONNECTION_CLOSE or APPLICATION_CLOSE. ## Data Limit Increments {#fc-credit}