Subject: [quicwg/base-drafts] Move stream type into frame type (#1431)

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jun 2018 04:29:40 -0700

During the discussion that became #1430 in Kista, @janaiyengar asked me to write this up, just so we could see what it looks like.

As the issue mentions, this becomes more viable now that the crypto stream won't be part of any of the stream type spaces, but off on its own.  To keep this sensible, I've deleted the stream 0 carve-outs where they were in the way of this change, but it won't actually be fully consistent until #1377 lands as well.

Fixes #1430.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Move stream type into frame type

-- File Changes --

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

-- Patch Links --

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 08 Jun 2018 11:40:35 +0000 (UTC)

Clarification: does this mean the stream intent at the QUIC layer as opposed to application layer mapping type?

-- 
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/1431#issuecomment-395735449

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Jun 2018 05:03:48 -0700

> Clarification: does this mean the stream intent at the QUIC layer as opposed to application layer mapping type?

As I read it, this is clearly at the QUIC layer, and QUIC (transport) doesn't really deal much with the application layer.

It might be good with some additional formal naming conventions such as peer initiated bidi stream, locally initiated uni stream, etc. such that HTTP QUIC and friends has a meaningful language and possibly also assign a number to the stream type as a value in 0 .. 3 but keeping the actual stream id specific to the stream type at both layers.

-- 
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/1431#issuecomment-395740360

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Jun 2018 13:58:57 +0000 (UTC)

martinthomson commented on this pull request.

Funny.  @janaiyengar was a strong proponent of the current design and argued against this approach when I suggested it.  I was convinced by that argument, and remain so.

Creating 4 of each type is a little unwieldy.  Worse when you consider that a server can never send 0x13 and a client can never send 0x12.  It isn't any more complicated to implement, but it isn't without costs.

Mostly, it is the secondary things that matter here.  When you are debugging, you need extra information to distinguish between stream 2 and stream 2 and stream 2 and stream 2.  Talking about streams requires that you are more explicit.  Yeah, it fixes the problem where people say N+1 and mean N+4, but is it really that useful a change?

Also, it ruins suggestions I made regarding PRIORITY, but that's not that important :)

-- 
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/1431#pullrequestreview-127172177

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Jun 2018 07:25:47 -0700

For debugging and documentation, the streams could be designated a suffix like stream 2bc, stream 2uc, stream 2bs, and stream 2us. This is far easier than the stream 2, 3, 4, 5 which says little about context.

-- 
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/1431#issuecomment-395777394

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Jun 2018 07:36:05 -0700

The debugging aspect is mitigated if you stick the type in the top two bits of a 64-bit integer locally.  So you'd see 0x00000002, 0x40000002, 0x80000002, or 0xc0000002.  Or you'd output with a prefix, e.g. CU2, SB2, etc.  But you can't encode that way on the wire, or only one of the types can be less than 4 bytes.

Yeah, I thought about trying to condense it to three types per frame, where one of them means "the only unidirectional stream I could be talking about" and the interpretation varies based on who's sending it.  It's only a step further than the two-type frames that imply directionality based on the sender and only provide bi/uni in a bit.  But I feel like the cost in consistent representation outweighed saving the frame types.  We already have the language that says you need to reject a frame that talks about a stream the sender isn't allowed to talk about, so that's no worse, even if no better.

How does it ruin PRIORITY again?

-- 
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/1431#issuecomment-395780478

---

From: Martin Thomson <[email-masked]>
Date: Sat, 09 Jun 2018 05:15:13 -0700

Having the extra space turns out to be handy: https://github.com/quicwg/base-drafts/pull/1422#pullrequestreview-127164641

-- 
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/1431#issuecomment-395964810

---

From: ianswett <[email-masked]>
Date: Sat, 09 Jun 2018 09:19:22 -0700

It's interesting to see this, but I favor the current approach unless this fixes some important issue I'm unaware of.  I don't think something being awkward reaches the bar of "important issue" at this point in the process.

-- 
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/1431#issuecomment-395981088

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jun 2018 08:55:26 -0700

I agree with Ian here.  What we have isn't ideal, but you can get used to it.  It would be easier if people didn't feel that it was necessary to correct someone every time they say N+1 but mean N+4, when intent is otherwise clear, but that is a small tax to pay.

FWIW, I experimented with an encoding for stream identifiers that used a 2 bit prefix and a varint that was 4/12/28/60.  The performance hit was considerable.

-- 
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/1431#issuecomment-396293329

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Jun 2018 18:15:33 +0000 (UTC)

@martinthomson, I'm curious about the source of the performance hit.  Was it simply from using a non-byte-aligned varint?  If so, that seems separate from this.

-- 
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/1431#issuecomment-396684983

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jun 2018 18:28:51 -0700

So I don't know for certain, I just had the numbers in the end.  I suspect that it was just the extra code needed to pull two lots of two bits from the first octet.  Obviously having an extra field is more work, but it was more costly than I anticipated.  I probably have the code on a branch still...

-- 
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/1431#issuecomment-397138052

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2018 00:08:43 +0000 (UTC)

@MikeBishop are we resolved on this?  (I don't have the code I wrote, sadly).

-- 
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/1431#issuecomment-400500835

---

From: janaiyengar <[email-masked]>
Date: Tue, 26 Jun 2018 17:59:13 -0700

I'm fine with closing this.

-- 
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/1431#issuecomment-400509453

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 21:26:47 -0700

While I continue to prefer this model conceptually, it doesn't sound like there's consensus to do this for v1.  I'm trying to insulate HTTP from the specifics of Stream ID layout so that nothing breaks if we adopt something like this in a future version.

-- 
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/1431#issuecomment-400538853

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 21:26:50 -0700

Closed #1431.

-- 
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/1431#event-1702956328