Subject: Re: [quicwg/base-drafts] Define terms for application actions (#2857)

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 01 Jul 2019 07:20:27 -0700

dtikhonov requested changes on this pull request.

> @@ -827,9 +827,9 @@ Servers initiate the shutdown of a connection by sending a GOAWAY frame
 on lower stream IDs were or might be processed in this connection, while
 requests on the indicated stream ID and greater were rejected. This enables
 client and server to agree on which requests were accepted prior to the
-connection shutdown.  This identifier MAY be zero if no requests were
-processed.  Servers SHOULD NOT increase the QUIC MAX_STREAMS limit after
-sending a GOAWAY frame.
+connection shutdown.  This identifier MAY be zero if no requests were processed.
+Servers SHOULD NOT permit additional transport streams after sending a GOAWAY

"transport stream" is new term not defined elsewhere in the document.

> @@ -927,12 +927,10 @@ All client-initiated bidirectional streams are used for HTTP requests and
 responses.  A bidirectional stream ensures that the response can be readily
 correlated with the request. This means that the client's first request occurs
 on QUIC stream 0, with subsequent requests on stream 4, 8, and so on. In order
-to permit these streams to open, an HTTP/3 client SHOULD send non-zero values
-for the QUIC transport parameters `initial_max_stream_data_bidi_local`. An
-HTTP/3 server SHOULD send non-zero values for the QUIC transport parameters
-`initial_max_stream_data_bidi_remote` and `initial_max_bidi_streams`. It is
-RECOMMENDED that `initial_max_bidi_streams` be no smaller than 100, so as to not
-unnecessarily limit parallelism.
+to permit these streams to open, an HTTP/3 server SHOULD configure non-zero
+minimum values for the number of permitted streams and the initial flow control
+window for each stream. It is RECOMMENDED that at least 100 requests be

"initial flow control window for each stream" makes it sound as if each stream's flow control window could be configured independently.

> +  data or possibly discovering that the stream has been closed because the peer
+  sent a STOP_SENDING frame ({{frame-stop-sending}});
+- end the stream (clean termination), resulting in a STREAM frame
+  ({{frame-stream}}) with the FIN bit set; and
+- reset the stream (abrupt termination), resulting in a RESET_STREAM frame
+  ({{frame-reset-stream}}), even if the stream was already ended.
+
+On the receiving part of a stream, application protocols need to be able to:
+
+- read data
+- abort reading of the stream and request closure, possibly resulting in a
+  STOP_SENDING frame ({{frame-stop-sending}})
+
+Applications also need to be informed of state changes on streams, including
+when the peer has initiated, reset, or aborted reading on a stream; when new
+data is available; and when data on the stream is blocked due to flow

> when data on the stream is blocked due to flow control

Does this refer to the endpoint's or peer's inability to write?

-- 
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/2857#pullrequestreview-256357958

---

From: ianswett <[email-masked]>
Date: Mon, 01 Jul 2019 07:20:43 -0700

ianswett commented on this pull request.

Thanks for doing this, it looks much better.

Should this be flow or congestion control?  And should there be a signal when the stream is unblocked so you can resume sending?

> @@ -1101,6 +1132,41 @@ suggested structure:
 -->

+## Required Operations on Connections
+
+There are certain operations which an application MUST be able to perform when
+interacting with the QUIC transport.  This document does not specify an API, but
+any implementation of this version of QUIC MUST expose the ability to perform
+the operations described in this section on a QUIC connection.
+
+When implementing the client role, applications need to be able to:
+
+- open a connection, which begins the exchange described in {{handshake}};
+- enable 0-RTT; and
+- be informed when 0-RTT has been accepted or rejected by a server.

I'm not certain the application needs to know about 0-RTT accept/reject, but I believe it does need to know when it can start sending 1RTT data?

+When implementing the client role, applications need to be able to:
+
+- open a connection, which begins the exchange described in {{handshake}};
+- enable 0-RTT; and
+- be informed when 0-RTT has been accepted or rejected by a server.
+
+When implementing the server role, applications need to be able to:
+
+- listen for incoming connections, which prepares for the exchange described in
+  {{handshake}};
+- if Early Data is supported, embed application-controlled data in the TLS
+  resumption ticket sent to the client; and
+- if Early Data is supported, retrieve application-controlled data from the
+  client's resumption ticket and enable rejecting Early Data based on that
+  information.

Servers need to expose whether incoming data is Early Data, correct? ie: for the Early Data header.

> @@ -505,11 +505,11 @@ this limit are not guaranteed to be accepted.
 
 ### Request Cancellation and Rejection {#request-cancellation}
 
-Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or
-STOP_SENDING frames, as appropriate) with an error code of
-HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client cancels a
-response, it indicates that this response is no longer of interest.
-Implementations SHOULD cancel requests by aborting both directions of a stream.
+Clients can cancel requests by resetting the request stream with an error code
+of HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client aborts

How about "Clients can cancel requests by resetting and aborting the request stream with an error code of HTTP_REQUEST_CANCELLED"?  I think that phrasing makes it clearer that you need to reset the write side and abort the read side in order to fully cancel a request?

> @@ -505,11 +505,11 @@ this limit are not guaranteed to be accepted.
 
 ### Request Cancellation and Rejection {#request-cancellation}
 
-Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or
-STOP_SENDING frames, as appropriate) with an error code of
-HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client cancels a
-response, it indicates that this response is no longer of interest.
-Implementations SHOULD cancel requests by aborting both directions of a stream.
+Clients can cancel requests by resetting the request stream with an error code
+of HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client aborts
+reading a response, it indicates that this response is no longer of interest.
+Implementations SHOULD cancel requests by terminating both directions of a

Do we define terminating?

-- 
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/2857#pullrequestreview-256355235

---

From: Mike Bishop <[email-masked]>
Date: Tue, 16 Jul 2019 13:24:41 -0700

@MikeBishop pushed 1 commit.

ca7b3edfc59210ac3c4cfabf2dc7ffeacb40ce88  Updates from review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2857/files/36ad00639195c13c7035cea167af5d84bdccdd35..ca7b3edfc59210ac3c4cfabf2dc7ffeacb40ce88