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

Clearer text for application errors #3226

Merged
merged 3 commits into from
Dec 3, 2019
Merged

Clearer text for application errors #3226

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9112fd7
Clearer text for application errors
martinthomson Nov 12, 2019
36192e6
only the application
martinthomson Nov 12, 2019
2ae9899
Reorder, tweak
martinthomson Nov 12, 2019
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
16 changes: 9 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
RESET_STREAM carries an application error code, for which the semantics are
defined by the application protocol. Only the application protocol is able to
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
Copy link
Member

Choose a reason for hiding this comment

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

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?

Copy link
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Contributor

Choose a reason for hiding this comment

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

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?

guarantee consistent state between endpoints. Application protocols SHOULD
define rules for handling streams that are prematurely cancelled by either
endpoint.


# Packets and Frames {#packets-frames}
Expand Down