Subject: [quicwg/base-drafts] Move crypto to stream 0, HTTP control to stream 1 (#456)

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 23:05:17 -0700

The nasty overloading in WINDOW_UPDATE was the only reason that we couldn't use stream 0 for identifying streams.  That's gone now.

A nice benefit is that this also makes the special exception for `initial_max_stream_id` go away.  0 is now a completely valid initial maximum stream ID.  In some protocols, that might even make sense.

Builds on #454, look at 16dee05d236ecf27c2d069b94d142a70258ef57c for just the relevant changes here.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Split WINDOW_UPDATE into MAX_DATA and MAX_STREAM_DATA
  * The hazards of renaming things automatically
  * Fix IANA table
  * Jana's review comments
  * Fix frame type numbers
  * Split BLOCKED into two
  * Move crypto to stream 0, HTTP control to stream 1

-- File Changes --

    M draft-ietf-quic-http.md (18)
    M draft-ietf-quic-tls.md (38)
    M draft-ietf-quic-transport.md (410)

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 20 Apr 2017 01:42:45 -0700

mikkelfj commented on this pull request.

 Connection flow control is a limit to the total bytes of stream data sent in
-STREAM frames on all streams contributing to connection flow control.  A
-receiver advertises credit for a connection by sending a WINDOW_UPDATE frame
-with the Stream ID set to zero (0x00).  A receiver maintains a cumulative sum of
-bytes received on all streams contributing to connection-level flow control, to
-check for flow control violations. A receiver may maintain a cumulative sum of
-bytes consumed on all contributing streams to determine the connection-level
-flow control offset to be advertised.
+STREAM frames on all streams.  A receiver advertises credit for a connection by
+sending a MAX_DATA frame.  A receiver maintains a cumulative sum of bytes

It is not clear if stream id 0 counts against this, even if it is not punished for violating the connection max_data limit.

-- 
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/456#pullrequestreview-33707104

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Apr 2017 02:52:00 -0700

martinthomson commented on this pull request.

The limiting mechanism is now a maximum number.  The smallest maximum that can be expressed is 0, so stream 0 is always OK.

-- 
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/456#discussion_r112413133

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Apr 2017 02:54:19 -0700

My bad, the TLS spec says that stream 0 doesn't count and this obviously removes that exception.  That's a problem, I agree.  Not sure what the right answer is here.  We previously agreed that stream 0 was exempt from connection flow control, mainly due to problems with completing the handshake with 0-RTT, but with Victor's proposed changes, maybe we can avoid that.  I'll restore the exemption for stream 0 in the meantime.

-- 
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/456#discussion_r112413599

---

From: Mike Bishop <[email-masked]>
Date: Thu, 20 Apr 2017 12:25:02 -0700

MikeBishop approved this pull request.

Crypto stream, still a special snowflake....

-- 
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/456#pullrequestreview-33863797

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Apr 2017 23:09:24 -0700

@janaiyengar, I'd like to merge this.  Please review; it's going to rot very quickly.

-- 
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/456#issuecomment-297915684

---

From: ekr <[email-masked]>
Date: Fri, 28 Apr 2017 00:17:19 -0700

ekr 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/456#pullrequestreview-35291702