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

From: MikkelFJ <[email-masked]>
Date: Thu, 17 Oct 2019 23:13:56 -0700

mikkelfj commented on this pull request.

I realize this is merged by now, but I still have a few comments.

> +## Required Operations on Streams
+
+There are certain operations which an application MUST be able to perform when
+interacting with QUIC streams.  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 stream.
+
+On the sending part of a stream, application protocols need to be able to:
+
+- write data, understanding when stream flow control credit
+  ({{data-flow-control}}) has successfully been reserved to send the written
+  data
+- 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.

This is unclear - what does it mean that "the stream was already ended"? I would say it is fair for an API to issue a soft error if you try to RESET (abrupt termination) after having issued a FIN request (clean termination), or vice version. Certainly I would not want a QUIC implementation tracking a stream handle indefinitely in case some app decides to reset it eventually.

> @@ -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.

But why does an application need to be able to enable 0-RTT? Isn't 0-RTT optional at transport level, and more so at the app level?

> +
+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.

An app should also be able to reject incoming connections, for example based on implementation specific criteria such as load or peer IP address.

> +
+- 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.
+
+In either role, applications need to be able to:
+
+- configure minimum values for the initial number of permitted streams of each
+  type, as communicated in the transport parameters ({{transport-parameters}});
+- control resource allocation of various types, including flow control and the
+  number of permitted streams of each type;
+- identify whether the handshake has completed successfully or is still ongoing

Given that hanshake keys must now be held forever, how can it be indicated that a handshake is complete?

-- 
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-303679855

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 11:02:17 -0700

MikeBishop commented on this pull request.

+

"End the stream" was the previous bullet, so I think it's reasonably clear what "already ended" should mean in this context.  If you look at the [sending stream states](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.1), this reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESET_STREAM.

Based on the state diagram, if an implementation was already in the "Data Recvd" state, they wouldn't send a RESET_STREAM, as they're already in a terminal state. Surfacing this through the API would be a reasonable choice.  Likewise, there's no path from "Reset Sent" or "Reset Recvd" to "Data Sent"; I think attempting to write to or close a reset stream will always be an error.

-- 
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#discussion_r338197139

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 11:04:30 -0700

-->

An application needs to be able to control whether 0-RTT is offered; you're correct that this phrasing implies that 0-RTT support is mandatory, which wasn't the intention.

-- 
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#discussion_r338198200

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 11:05:57 -0700

That seems like a worthwhile feature for a QUIC implementation to expose, but doesn't seem like one we should mandate every QUIC implementation must expose.

-- 
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#discussion_r338198853

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 11:07:51 -0700

The phrases "handshake completes," "handshake is complete," "handshake has completed," etc. occur throughout the document.  If you believe that there can be no such concept, please open a separate issue and explain in detail.

-- 
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#discussion_r338199837

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 Oct 2019 19:56:47 +0000 (UTC)

+

So you mean to say that an application should be able to reset a stream at an arbitrary point after the stream has sent a FIN bit? If so, I don't think that is a good idea. In my view that would be an API error of invalid handle or invalid handle state. It's one thing to allow races between RESET and FIN but to require it forever is different.

-- 
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#discussion_r338247997

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 Oct 2019 12:57:31 -0700

I can agree to 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/2857#discussion_r338248305

---

From: MikkelFJ <[email-masked]>
Date: Wed, 23 Oct 2019 13:02:22 -0700

I'm not objecting to this term being defined, but I do suspect there is an issue if the now infamous PR #3121 gets merged. But, as it hasn't yet, and there is pushback, I'll see where it goes. Defining exactly what is, or might be, wrong requires a deep analysis because one peer can consider a handshake complete without the other peer agreeing, and sometimes that might be fine while in other cases not so much, like path migration.

-- 
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#discussion_r338250329

---

From: Mike Bishop <[email-masked]>
Date: Mon, 28 Oct 2019 13:19:10 -0700

+

Rather than having this discussion on a closed PR, let's open a separate 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/2857#discussion_r339771972