Subject: [quicwg/base-drafts] Stop reserving application error codes (#1922)

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 23:09:04 -0700

We really don't need to do this.  As observed, the error code in
RST_STREAM really doesn't matter once you have requested that it stop.

I know that this wasn't a universally-held opinion, but we don't need to
stomp on values in the application protocol, so we shouldn't.  (Igor
suggested a new frame type, and that is maybe cleaner, but it's
wasteful when it won't be used, so I think that this is better.)

I've gone with the minimal change to HTTP.  The bigger change would be to recommend the use of NO_ERROR for this case and to renumber error code.  I'll let @MikeBishop decide what happens there.

Closes #1804.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Stop reserving application error codes

-- File Changes --

    M draft-ietf-quic-http.md (6)
    M draft-ietf-quic-transport.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1922.patch
https://github.com/quicwg/base-drafts/pull/1922.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/1922

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 23:27:43 -0700

kazuho commented on this pull request.

> @@ -1530,7 +1530,7 @@ The entries in the following table are registered by this document.
 | ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
 | Name                                | Code       | Description                              | Specification          |
 | ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
-| STOPPING                            | 0x0000     | Reserved by QUIC                         | {{QUIC-TRANSPORT}}     |
+| HTTP_STOPPING                       | 0x0000     | Solicited stream reset                   | {{http-error-codes}}   |

Can we renumber NO_ERROR to 0 and use 1 for HTTP_STOPPING, now that application-level error codes are not defined in the transport document?

-- 
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/1922#pullrequestreview-168685372

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 23:29:09 -0700

martinthomson commented on this pull request.

See my opening comment.  I think we should, but I will defer to Mike on that point.

-- 
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/1922#discussion_r228417181

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 23:35:44 -0700

Oh. Sorry for the fuss. I was too eager to look at the diffs.

-- 
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/1922#discussion_r228418197

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 00:32:40 -0700

mikkelfj commented on this pull request.

> @@ -706,9 +706,14 @@ frames count toward flow control.
 
 A STOP_SENDING frame requests that the receiving endpoint send a RST_STREAM
 frame.  An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM
-frame for that stream, and can use an error code of STOPPING.  If the
-STOP_SENDING frame is received on a send stream that is already in the "Data
-Sent" state, a RST_STREAM frame MAY still be sent in order to cancel
+frame for that stream.  An endpoint can use any application error code, though
+they SHOULD send the error code with a value of 0.  The endpoint that sends a

I think there could be non-fatal errors resulting in STOP_SENDING so “should send 0” is not that helpful.

For example, error could be - upstream bucket is full, or logging feedback disabled on channel.

-- 
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/1922#pullrequestreview-168700014

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 01:16:23 -0700

How about reflecting the STOP_SENDING error code in the RST frame?
That avoids race conditions with other error codes - but perhaps it is best to leave it to the application altogether, and not even (strongly) recommending sending 0.

-- 
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/1922#issuecomment-433326746

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Oct 2018 01:24:26 -0700

> How about reflecting the STOP_SENDING error code in the RST frame?

I like that idea.  I'll do 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/1922#issuecomment-433328899

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Oct 2018 01:27:51 -0700

@martinthomson pushed 1 commit.

dcabe2a  Echo STOP_SENDING code in RST_STREAM, remove STOPPING from HTTP

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1922/files/3fcaee0c116533f2c18fc862e14c78591d6314bb..dcabe2a0d2e44e73c73c9a5e0a76f003681cd9d7

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 01:00:01 -0700

3a0d65a  Remove 0 recommendation properly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1922/files/dcabe2a0d2e44e73c73c9a5e0a76f003681cd9d7..3a0d65ae11fa6ceb5a1470a84ded6696c6b67083

---

From: Nick Banks <[email-masked]>
Date: Mon, 29 Oct 2018 06:34:32 -0700

nibanks commented on this pull request.

> @@ -1530,7 +1526,6 @@ The entries in the following table are registered by this document.
 | ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
 | Name                                | Code       | Description                              | Specification          |
 | ----------------------------------- | ---------- | ---------------------------------------- | ---------------------- |
-| STOPPING                            | 0x0000     | Reserved by QUIC                         | {{QUIC-TRANSPORT}}     |
 | HTTP_NO_ERROR                       | 0x0001     | No error                                 | {{http-error-codes}}   |

You changed HTTP_NO_ERROR to 0x00 above, but forgot to change it here.
```suggestion
 | HTTP_NO_ERROR                       | 0x0000     | No error                                 | {{http-error-codes}}   |
```

-- 
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/1922#pullrequestreview-169300778

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 12:06:23 -0700

MikeBishop requested changes on this pull request.

One place where the change goes further than I thought we'd agreed; otherwise, looks good.

> @@ -706,9 +706,13 @@ frames count toward flow control.
 
 A STOP_SENDING frame requests that the receiving endpoint send a RST_STREAM
 frame.  An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM
-frame for that stream, and can use an error code of STOPPING.  If the
-STOP_SENDING frame is received on a send stream that is already in the "Data
-Sent" state, a RST_STREAM frame MAY still be sent in order to cancel
+frame for that stream.  An endpoint can use any application error code in the
+RST_STREAM frame, though they can copy the error code from the STOP_SENDING
+frame if no other option is available.  The endpoint that sends a STOP_SENDING

"You can X, though you can (subset of X)."  This feels unwieldy.  I'd probably recommend one, rather than stating the possibility.  "An endpoint SHOULD copy the error code from the STOP_SENDING frame, but MAY use any other application error code."

> @@ -2491,13 +2495,11 @@ connection in a recoverable state, the endpoint can send a RST_STREAM frame
 ({{frame-rst-stream}}) with an appropriate error code to terminate just the
 affected stream.
 
-Other than STOPPING ({{solicited-state-transitions}}), RST_STREAM MUST be
-instigated by the application and MUST carry an application error code.
-Resetting a stream without knowledge of the application protocol could cause the
-protocol to enter an unrecoverable state.  Application protocols might require
-certain streams to be reliably delivered in order to guarantee consistent state
-between endpoints.
-
+RST_STREAM MUST be instigated by the application.  RST_STREAM carries an

Along with the reference to STOPPING, you've removed the ability for the QUIC stack to handle STOP_SENDING internally.  I don't think that's an improvement, and perhaps not intended 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/1922#pullrequestreview-169464812

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 17:41:18 -0700

@martinthomson pushed 2 commits.

6550f83  Reword copying sentence
a554a0f  Consistency fix for NO_ERROR

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1922/files/3a0d65ae11fa6ceb5a1470a84ded6696c6b67083..a554a0fc45f724f55df32762864e4e770946192b

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:28:20 -0700

Copying the code from STOP_SENDING works, doesn't it?

-- 
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/1922#discussion_r229166195

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 21:18:41 -0700

MikeBishop commented on this pull request.

"RST_STREAM MUST be instigated by the application."  That means the QUIC stack never initiates a RST, which is unrelated to what error code you put in the RST_STREAM that it's not initiating.

Perhaps we say, "Unless in response to a STOP_SENDING ({{solicited...}}), RST_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/pull/1922#discussion_r229171876

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 21:27:26 -0700

065757e  Allow STOP_SENDING to trigger RST_STREAM

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1922/files/a554a0fc45f724f55df32762864e4e770946192b..065757e5652e37e4a4d816f106bba1ef1f8a5344

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 21:27:42 -0700

How does this sound?

> RST_STREAM MUST be instigated by the protocol using QUIC, either directly or
through the receipt of a STOP_SENDING frame from a peer.

-- 
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/1922#discussion_r229172827

---

From: Mike Bishop <[email-masked]>
Date: Tue, 30 Oct 2018 11:59:59 -0700

MikeBishop approved this pull request.

-- 
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/1922#pullrequestreview-169943088

---

From: janaiyengar <[email-masked]>
Date: Tue, 30 Oct 2018 16:00:27 -0700

janaiyengar approved this pull request.

-- 
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/1922#pullrequestreview-170036704

---

From: janaiyengar <[email-masked]>
Date: Tue, 30 Oct 2018 23:00:26 +0000 (UTC)

LGTM. I think @mikkelfj 's idea of reflecting the STOP_SENDING makes this a lot better. My concern in the past has been that requiring a RST_STREAM of the transport but leaving it up to the application to decide what error code to use creates a bad dependency. Allowing the transport to reflect the error code resolves this issue.

-- 
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/1922#issuecomment-434500935

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 17:16:38 -0700

Merged #1922 into master.

-- 
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/1922#event-1936622781