Subject: [quicwg/base-drafts] Unidirectional and bidirectional streams (#885)

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 03:58:15 +0000 (UTC)

This is #872 with some additional exposition and one significant change.

Client-initiated streams are now EVEN.

Server initiated streams are now ODD.

This is a pretty noticeable change, because it inverts the current sign, and
might cause some disruption in implementations.  However, it makes stream 0
work within the framework better.  It wasn't clear what Ryan's intent was with
respect to numbering, but I wouldn't have noticed this until I noticed a
conflict between prose and the table.

Closes #643, #656, #720, #872, #175.

This does not close the other issues that were addressed by #643, because this
doesn't include any changes in the HTTP draft.  I'll create a follow-up PR for
that.

(We can argue about bit placement later, I'm just trying to make this as good as it can be.)
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Identify unidirectional streams by the 2nd bit in the stream ID
  * Address nits
  * invert
  * clarify
  * more
  * Remove unnecessary language
  * Merge branch 'Unidirectional' of https://github.com/RyanAtGoogle/base-drafts into biuni-wat
  * Unidirection and bidirectional streams

-- File Changes --

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

-- Patch Links --

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 05:05:02 +0000 (UTC)

@martinthomson pushed 1 commit.

f5b735a  Fixup

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/885/files/82f6b8750cc02f33102778536d95bd22c088bd2f..f5b735a861075fbe261d0f8482e205d7cd558894

---

From: ianswett <[email-masked]>
Date: Wed, 18 Oct 2017 12:50:07 +0000 (UTC)

ianswett commented on this pull request.

Thanks for clarifying the definition of unidirectional and bidirectional.  And I agree this is currently an inconsistency.

I'm a bit worried this change will create a lot of confusion for people familiar with HTTP/2.  The alternative would be to make the crypto stream 1 again.(Yes, I know you probably hate that, but it is simple).

-- 
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/885#pullrequestreview-70196814

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Oct 2017 23:19:52 +0000 (UTC)

mikkelfj commented on this pull request.

-Streams can be created either by the client or the server, can concurrently send
+Either type of stream can be created by either endpoint, can concurrently send
 data interleaved with other streams, and can be cancelled.

Not entirely clear which endpoint can cancel.

-- 
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/885#pullrequestreview-70387374

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Oct 2017 16:20:30 -0700

-Stream ID 0 (0x0) is reserved for the cryptographic handshake.  Stream 0 MUST
-NOT be used for application data, and is the first client-initiated stream.
+Stream ID 0 (0x0) is a client-initiated, bidirectional stream that is used for
+the cryptographic handshake.  Stream 0 MUST NOT be used for application data.

handshake and subsequent key exchanges?

-- 
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/885#pullrequestreview-70387489

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Oct 2017 16:22:37 -0700

> @@ -2706,6 +2739,7 @@ shown in the following figure and described below.
                                  v
                  recv FIN/  +--------+    send FIN/
                  recv RST   |        |    send RST
+                 recv UNI   |        |    send UNI
                   ,---------|  open  |-----------.

Isn't send and recv UNI swapped?

-- 
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/885#pullrequestreview-70387827

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Oct 2017 23:24:43 +0000 (UTC)

> @@ -3141,7 +3179,8 @@ is increased.
 The final offset is the count of the number of octets that are transmitted on a
 stream.  For a stream that is reset, the final offset is carried explicitly in
 the RST_STREAM frame.  Otherwise, the final offset is the offset of the end of
-the data carried in STREAM frame marked with a FIN flag.
+the data carried in STREAM frame marked with a FIN flag, or 0 in the case of
+incoming unidirectional streams.

in _the_ 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/885#pullrequestreview-70388142

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 16:29:37 -0700

martinthomson commented on this pull request.

                                  v

Honestly, I didn't check (the state machine is on borrowed time right now), but you are right.

-- 
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/885#discussion_r145569331

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 16:29:50 -0700

That's not important at this 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/885#discussion_r145569362

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 23:29:55 +0000 (UTC)

As above.

-- 
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/885#discussion_r145569369

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 16:30:11 -0700

442dc99  Add article

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/885/files/f5b735a861075fbe261d0f8482e205d7cd558894..442dc99647bfb200ac1534328008aa4d16fa7bb3

---

From: MikkelFJ <[email-masked]>
Date: Wed, 18 Oct 2017 23:38:14 +0000 (UTC)

Detail, but the RST_STREAM just above is referenced as _the_ RST_STREAM - is that intentional?

-- 
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/885#discussion_r145570496

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Oct 2017 23:42:03 +0000 (UTC)

3541a42  Detail

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/885/files/442dc99647bfb200ac1534328008aa4d16fa7bb3..3541a42a346b6c42b931b895ec5c31dbc2b68c66

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Oct 2017 02:24:49 +0000 (UTC)

> I'm a bit worried this change will create a lot of confusion for people familiar with HTTP/2. The alternative would be to make the crypto stream 1 again.(Yes, I know you probably hate that, but it…

I realize that, but then we're already there.  Rather than requests on every other stream, we have every fourth stream.  Better to have the clean break in my opinion.  Also, the number of uses for stream IDs in HTTP is limited, and could even be eliminated entirely, depending on how we manage header compression.

-- 
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/885#issuecomment-337781141

---

From: ianswett <[email-masked]>
Date: Thu, 19 Oct 2017 05:48:05 -0700

ianswett approved this pull request.

I'm happy with this, but adding Ryan as a reviewer since this is landing on top of his PR.

-- 
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/885#pullrequestreview-70523356

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 19 Oct 2017 09:43:27 -0700

If we're revisiting stream numbering I'll make a plea to release stream id 0 from being the crypto stream and instead make it an invalid stream id. It's a tad annoying that sometimes stream_id=0 means crypto stream (in a STREAM frame) and sometimes it mean the whole connection (MAX_STREAM_DATA). So if we made the crypto stream 1, then we'd be able to keep the current even/odd ness and eliminate the minor wart around stream_id 0.

What do you think?

-- 
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/885#issuecomment-337967197

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Oct 2017 16:47:49 +0000 (UTC)

@RyanAtGoogle In general I prefer 0 to be invalid and as such I am in line with your thinking. However, I did find crypto 0 to be helpful because any stream that is not crypto is handled via normal life time requirements whereas the crypto stream is sent to dedicated handlers. Unlike largest received packet number, the crypto stream always exists and any inbound stream will either be stream 0, or something to be validated against stream limits etc.

-- 
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/885#issuecomment-337968411

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Oct 2017 23:13:11 +0000 (UTC)

MAX_STREAM_DATA with a Stream ID of 0 is perfectly valid.  It sets the flow control for stream 0.  I think that you are confusing that with MAX_DATA.  We dispensed with 0 as a special value for that a long time ago.

The special-ness for stream 0 punches right through any issues of frames or encoding; those are all perfectly consistent with other frames.  It's the packet protection rules that are crazy for stream 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/885#issuecomment-338063251

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 19 Oct 2017 16:20:29 -0700

Ah, yes good point. Seems reasonable to me then.

-- 
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/885#issuecomment-338064337

---

From: janaiyengar <[email-masked]>
Date: Thu, 26 Oct 2017 19:36:22 +0000 (UTC)

Thanks for writing this up -- this PR 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/885#issuecomment-339777155

---

From: janaiyengar <[email-masked]>
Date: Thu, 26 Oct 2017 12:36:47 -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/885#pullrequestreview-72315299

---

From: afrind <[email-masked]>
Date: Fri, 27 Oct 2017 08:59:18 -0700

afrind commented on this pull request.

> -the client or even-numbered for the server) but which it has not yet
-created, it MUST close the connection with error code STREAM_STATE_ERROR.
+ID.  The least significant two bits of the Stream ID are used to identify the
+type of stream (unidirectional or bidirectional) and the initiator of the
+stream.
+
+The least significant bit (0x1) of the Stream ID identifies the initiator of the
+stream.  Clients initiate even-numbered streams (those with the least
+significant bit set to 0); servers initiate even-numbered streams (with the bit
+set to 1).  Separation of the stream identifiers ensures that client and server
+are able to open streams without the latency imposed by negotiating for an
+identifier.
+
+If an endpoint receives a frame for a stream that it expects to initiate (i.e.,
+odd-numbered for the client or even-numbered for the server), but which it has
+not yet opened but which it has not yet created, it MUST close the connection

Some duplicate text here 'but which it has not yet opened but which it has not yet created'

-- 
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/885#pullrequestreview-72551948

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Oct 2017 04:25:01 +0000 (UTC)

665dc8b  Remove duplication

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/885/files/3541a42a346b6c42b931b895ec5c31dbc2b68c66..665dc8b62955fd5115e83808143b1821bfa18ee0

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Oct 2017 21:26:56 -0700

Merged #885.

-- 
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/885#event-1315955569