Subject: Re: [quicwg/base-drafts] Make HTTP frames a TLV format. This has several advantages: (#2235)

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 14:20:01 -0800

We could have h3 use both TV and TLV: for example we say that
- all even types are TV, and must be negotiated before use (or in base spec)
- all odd types are TLV, and can be used without negotiation and ignored on receipt if unknown

This allows efficient encoding while preserving extensibility.

-- 
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/2235#issuecomment-451295817

---

From: MikkelFJ <[email-masked]>
Date: Thu, 03 Jan 2019 22:23:22 +0000 (UTC)

let's not over-engineer more than we already have

-- 
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/2235#issuecomment-451296608

---

From: janaiyengar <[email-masked]>
Date: Thu, 03 Jan 2019 17:05:51 -0800

I wasn't in the room where it happened, but I can imagine one reason for doing LTV in HTTP/2 might have been that you need to read out frames from the underlying byte-stream before demuxing and parsing them. A frame reader only needs Length before reading out the entire frame and passing it on to the parser. QUIC is different in that the entire frame is present when the length is read.

I think this is a simple enough change, and there are straightforward benefits. We expect to see some changes with more implementation experience in the HTTP mapping, so I'd like to push for this PR.

@ekr -- this discussion should be happening on an issue. Can you open an 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/2235#issuecomment-451327554

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 04 Jan 2019 05:35:03 -0800

@janaiyengar writes, in part (emphasis added):
> QUIC is different in that the _entire frame is present_ when the length is read.

I don't understand what you mean by 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/2235#issuecomment-451444878

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 04 Jan 2019 07:33:44 -0800

Yeah I don't follow either. The h3 layer is presented an in-order byte stream for each stream but it still needs to parse out H3 frames. While there are some loose assurances on frame ordering I don't know it QUIC is so different from H2, even with separate streams 

-- 
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/2235#issuecomment-451477087

---

From: janaiyengar <[email-masked]>
Date: Fri, 04 Jan 2019 16:02:59 -0800

@dtikhonov, @LPardue: Urgh, yes, sorry, I was not thinking straight. I was incorrect.

LTV or TLV, I don't have a strong preference either way.

-- 
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/2235#issuecomment-451605218

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Jan 2019 14:34:25 -0800

I interpreted @janaiyengar's comment to mean that when you read a QUIC frame it's in a datagram, so it's probably all sitting in memory.  With a streamed frame, you might not have all of the frame in place.  You might only have the length.

-- 
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/2235#issuecomment-451781464

---

From: Lucas Pardue <[email-masked]>
Date: Sun, 06 Jan 2019 15:46:36 -0800

Yeah I think we are all in agreement on 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/2235#issuecomment-451786776

---

From: Mike Bishop <[email-masked]>
Date: Mon, 07 Jan 2019 12:59:34 -0800

The previous discussion was #1351.  The conclusion there was that the order doesn't matter a great deal (under the assumption that you need both), and so consistency with HTTP/2 was the tie-break.

If there's a desire to enable length-less frames, that's an argument for TLV.  However, I don't think switching on the type value first is terribly compelling -- there doesn't seem to be a great difference between:
- passing your frame parser the type and expecting it to tell you how many bytes of the stream it processed and whether the frame was valid
- passing your frame parser the type and length and expecting it to tell you if the frame was mis-sized

-- 
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/2235#issuecomment-452079678

---

From: janaiyengar <[email-masked]>
Date: Mon, 07 Jan 2019 18:00:30 -0800

@martinthomson 
> I interpreted @janaiyengar's comment to mean that when you read a QUIC frame it's in a datagram, so it's probably all sitting in memory. With a streamed frame, you might not have all of the frame i…

Yes, that's exactly what I meant, but this discussion is about HTTP frames, which is what I had confused in my mind.

-- 
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/2235#issuecomment-452148025