Subject: [quicwg/base-drafts] Clearer text for application errors (#3226)

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Nov 2019 19:55:29 -0800

This cribs Lucas&#39; proposed tweak and makes a few other tiny adjustments.

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

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

-- Commit Summary --

  * Clearer text for application errors

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 12 Nov 2019 06:07:15 -0800

mikkelfj commented on this pull request.

> @@ -2720,17 +2720,19 @@ connection in a recoverable state, the endpoint can send a RESET_STREAM frame
 ({{frame-reset-stream}}) with an appropriate error code to terminate just the
 affected stream.
 
-RESET_STREAM MUST be instigated by the protocol using QUIC.  RESET_STREAM
-carries an application error code.  Only the application protocol is able to
+RESET_STREAM MUST be instigated by the application protocol that uses QUIC.

It's more like a transport MUST NOT - surely an application protocol can get through a connection without sending a RESET.

-- 
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/3226#pullrequestreview-315556738

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 12 Nov 2019 08:01:56 -0800

LPardue commented on this pull request.

>  cause a stream to be terminated.  A local instance of the application protocol
 uses a direct API call and a remote instance uses the STOP_SENDING frame, which
 triggers an automatic RESET_STREAM.
 
-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.  Application protocols SHOULD define rules for handling
-streams that are prematurely cancelled by either endpoint.
+Resetting a stream without the involvement of the application protocol could
+cause the application protocol to enter an unrecoverable state.  Application
+protocols might require certain streams to be reliably delivered in order to

to split hairs what does "might require certain streams to be reliably delivered" really mean here? Streams produce reliable byte streams. Is the intent more to say something like "applications expect streams to run to completion" and that premature exit causes that assumption to break?

-- 
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/3226#pullrequestreview-315647334

---

From: ianswett <[email-masked]>
Date: Tue, 12 Nov 2019 08:09:13 -0800

ianswett commented on this pull request.

Small comments

STOP_SENDING instigates RESET_STREAM, so this is a bit of a confusing statement.

+1 to Lucas point.  Personally, I'd delete this sentence because I think it's not adding much and as written it's confusing.

-- 
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/3226#pullrequestreview-315649845

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Nov 2019 10:12:55 -0800

MikeBishop commented on this pull request.

```suggestion
RESET_STREAM MUST only be instigated by the application protocol that uses QUIC.
```
@mikkelfj is right -- in isolation, this reads like a requirement on the application, not a restriction on everyone else.

It's the "critical stream" idea from HTTP/3 -- if you blow up a request stream, the HTTP connection is fine.  If you blow up a QPACK stream, the connection dies in flames.  Some streams are application-critical, and only the application knows which, so only the application can decide which streams to kill.  In a transport world, though, "reliably delivered" brings up different overtones.  Maybe "Resetting certain streams could disrupt the consistency of application-layer state between the endpoints."?

As to confusion, this is the rationale for the restriction in the previous paragraph.  Maybe putting the rationale first and following with "Therefore, RESET_STREAM MUST only be instigated...." would help?

-- 
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/3226#discussion_r345360528

---

From: MikkelFJ <[email-masked]>
Date: Tue, 12 Nov 2019 10:16:35 -0800

@ianswett from memory, but isn't that still the app doing this? STOP_SENDING can have the application signalling RESET, but it requires the app to choose the error/status code.

-- 
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/3226#discussion_r345365578

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Nov 2019 13:17:41 -0800

@martinthomson pushed 1 commit.

36192e6c3858e5431a60a63859547a661b46373f  only the application

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3226/files/9112fd7fa9c72a51c732e55b6c8c88707ae4e3bb..36192e6c3858e5431a60a63859547a661b46373f

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Nov 2019 13:21:03 -0800

2ae98990a35cbecba177a56c71b9db7bd0d57963  Reorder, tweak

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3226/files/36192e6c3858e5431a60a63859547a661b46373f..2ae98990a35cbecba177a56c71b9db7bd0d57963

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 12 Nov 2019 15:50:14 -0800

LPardue approved this pull request.

lgtm

-- 
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/3226#pullrequestreview-315921767

---

From: Marten Seemann <[email-masked]>
Date: Tue, 12 Nov 2019 18:04:32 -0800

marten-seemann 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/3226#pullrequestreview-315961131