Subject: HTTP Mapping: Fixing streams-in-streams

From: Mike Bishop <[email-masked]>
Date: Thu, 1 Dec 2016 23:35:22 +0000

We have the existing document which puts everything on a single stream and retains HTTP/2 framing.  At the WG meeting, I heard substantial desire to move as much as possible off to separate streams per request.  There was also discussion about how to modify HPACK (Buck has a proposal via e-mail; I have a draft) to enable this, but from side conversations, I think there's also a desire to reuse HPACK code where possible and minimize changes.

What I'd like to propose as the path forward is this:

  *   Change the mapping document to use the two-streams-per-request model described in draft-bishop-quic-http-and-qpack<https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack> section 3.1 with some of the frame redefinitions from section 3.2.
  *   Augment header-bearing frames with a sequence number
  *   Continue to use unmodified HPACK with a requirement that frames be fed to the decoder in order for now

This should produce no worse head-of-line blocking than currently exists, reuses existing HPACK code, and lets us make progress on the current draft.  In parallel and as we have people to work on it, we can decide to what extent we want to modify HPACK to reduce HOL-blocking issues.  (I'd encourage Buck to generate a short draft on his idea as well, so we have two ideas to compare.)

I'd specifically like opinions from the WG on whether that's the path we want to move forward with, or if there's an alternative I haven't heard.  If that's acceptable to the WG, I'll start a pull request for review.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 5 Dec 2016 12:26:07 -0800

Thanks for the work, Mike. I like this approach -- it's a great way to
separate the header compression issue from the issue of a clean mapping of
HTTP headers/data to QUIC streams. I think we should discuss the HTTP to
QUIC stream mapping proposal you've outlined, but should we do that on an
issue? Or a separate thread?

FWIW, I like this mapping approach, where HTTP headers and body are mapped
to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and
should be lightweight, which means that they can be used instead of
building a new framing format for HTTP headers vs body.

On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop <[email-masked]>
wrote:

> We have the existing document which puts everything on a single stream and
> retains HTTP/2 framing.  At the WG meeting, I heard substantial desire to
> move as much as possible off to separate streams per request.  There was
> also discussion about how to modify HPACK (Buck has a proposal via e-mail;
> I have a draft) to enable this, but from side conversations, I think
> there’s also a desire to reuse HPACK code where possible and minimize
> changes.
>
>
>
> What I’d like to propose as the path forward is this:
>
>    - Change the mapping document to use the two-streams-per-request model
>    described in draft-bishop-quic-http-and-qpack
>    <https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack> section
>    3.1 with some of the frame redefinitions from section 3.2.
>    - Augment header-bearing frames with a sequence number
>    - Continue to use unmodified HPACK with a requirement that frames be
>    fed to the decoder in order for now
>
>
>
> This should produce no worse head-of-line blocking than currently exists,
> reuses existing HPACK code, and lets us make progress on the current
> draft.  In parallel and as we have people to work on it, we can decide to
> what extent we want to modify HPACK to reduce HOL-blocking issues.  (I’d
> encourage Buck to generate a short draft on his idea as well, so we have
> two ideas to compare.)
>
>
>
> I’d specifically like opinions from the WG on whether that’s the path we
> want to move forward with, or if there’s an alternative I haven’t heard.
> If that’s acceptable to the WG, I’ll start a pull request for review.
>

---

From: Ian Swett <[email-masked]>
Date: Mon, 5 Dec 2016 15:36:05 -0500

Agreed, moving forward with the existing level of HOL blocking and
improving upon it seems practical, since it seems very likely we'll move to
the two-streams-per-request model no matter what.

On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar <[email-masked]> wrote:

>> We have the existing document which puts everything on a single stream
>> and retains HTTP/2 framing.  At the WG meeting, I heard substantial desire
>> to move as much as possible off to separate streams per request.  There was
>>    - Change the mapping document to use the two-streams-per-request
>>    model described in draft-bishop-quic-http-and-qpack
>>    <https://tools.ietf.org/html/draft-bishop-quic-http-and-qpack>
>>    section 3.1 with some of the frame redefinitions from section 3.2.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 5 Dec 2016 21:52:19 +0000

I’ve created a pull request with the following proposal here:  https://github.com/quicwg/base-drafts/pull/71

Feedback welcome, as always.

From: Ian Swett [mailto:[email-masked]]
Sent: Monday, December 5, 2016 12:36 PM
To: Jana Iyengar <[email-masked]>
Cc: Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: HTTP Mapping: Fixing streams-in-streams

Agreed, moving forward with the existing level of HOL blocking and improving upon it seems practical, since it seems very likely we'll move to the two-streams-per-request model no matter what.

On Mon, Dec 5, 2016 at 3:26 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the work, Mike. I like this approach -- it's a great way to separate the header compression issue from the issue of a clean mapping of HTTP headers/data to QUIC streams. I think we should discuss the HTTP to QUIC stream mapping proposal you've outlined, but should we do that on an issue? Or a separate thread?

FWIW, I like this mapping approach, where HTTP headers and body are mapped to a stream-pair. As I've noted earlier, QUIC's streams are ephemeral and should be lightweight, which means that they can be used instead of building a new framing format for HTTP headers vs body.

On Thu, Dec 1, 2016 at 3:35 PM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
We have the existing document which puts everything on a single stream and retains HTTP/2 framing.  At the WG meeting, I heard substantial desire to move as much as possible off to separate streams per request.  There was also discussion about how to modify HPACK (Buck has a proposal via e-mail; I have a draft) to enable this, but from side conversations, I think there’s also a desire to reuse HPACK code where possible and minimize changes.

This should produce no worse head-of-line blocking than currently exists, reuses existing HPACK code, and lets us make progress on the current draft.  In parallel and as we have people to work on it, we can decide to what extent we want to modify HPACK to reduce HOL-blocking issues.  (I’d encourage Buck to generate a short draft on his idea as well, so we have two ideas to compare.)

I’d specifically like opinions from the WG on whether that’s the path we want to move forward with, or if there’s an alternative I haven’t heard.  If that’s acceptable to the WG, I’ll start a pull request for review.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Dec 2016 17:52:46 +0000

Given some positive feedback and no negative so far, I’m going to go ahead and merge this.  Feedback continues to be welcome.

From: QUIC [mailto:[email-masked]] On Behalf Of Mike Bishop
Sent: Monday, December 5, 2016 1:52 PM
To: Ian Swett <[email-masked]>; Jana Iyengar <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: RE: HTTP Mapping: Fixing streams-in-streams

From: Ian Swett [mailto:[email-masked]]
Sent: Monday, December 5, 2016 12:36 PM
To: Jana Iyengar <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: HTTP Mapping: Fixing streams-in-streams

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 8 Dec 2016 09:58:08 -0800

One question I have.  The text refers to the control data streams being
exempt from flow control.  In our deployment, headers are exempt from the
connection level flow control, but stream level flow control still applies.
  Is the full exemption intentional?

Beyond that, I'm interested to know more of the rationale behind flow
control.  Tidbits I've heard are not very satisfactory to me, it seems like
priorities (which are not fully baked for QUIC yet) would be the more
appropriate mechanism.

On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop <[email-masked]>
wrote:

> Given some positive feedback and no negative so far, I’m going to go ahead
> and merge this.  Feedback continues to be welcome.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Mike Bishop
> *Sent:* Monday, December 5, 2016 1:52 PM
> *To:* Ian Swett <[email-masked]>; Jana Iyengar <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>
> *Subject:* RE: HTTP Mapping: Fixing streams-in-streams
>
>
>
> I’ve created a pull request with the following proposal here:
> https://github.com/quicwg/base-drafts/pull/71
>
>
>
> *From:* Ian Swett [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, December 5, 2016 12:36 PM
> *To:* Jana Iyengar <[email-masked]>
> *Cc:* Mike Bishop <[email-masked]>; IETF QUIC WG <
> [email-masked]>
> *Subject:* Re: HTTP Mapping: Fixing streams-in-streams
>
>
>

-- 
Charles 'Buck' Krasic | Software Engineer | [email-masked] | +1 (408)
412-1141

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Dec 2016 20:12:55 +0000

I actually did update the text to specify “connection-level,” since that’s what the transport draft allows the application to do.  In HTTP/2, only DATA frames are flow-controlled at all, a subject of some debate in the HTTP WG at the time.

The rationale either way is that payload on the control streams is being consumed by the protocol implementation itself, not by something above it, so those should flow unimpeded and can be trusted to read and process promptly, bugs notwithstanding.  There are other guards against an abusive peer:  If the peer opens too many streams they’ll produce a violation at the QUIC layer, and you have the option of putting a smaller per-stream flow control window to begin with.

Flow control and priority are related, but serve different purposes.  Flow control limits how much unprocessed data I have sitting around, while priority dictates how I should allocate a scarce resource (whether that’s processing time or bandwidth on the return direction).  A thick client will very rarely want to flow-control the server – in practice, they open the windows as wide as possible and use priority, as you suggest.  The server, on the other hand, wants to carefully bound memory allocations per connection – especially where the application actually consuming the data isn’t fully reliable from the protocol implementation’s point of view.  Flow control allows unread data flowing upstream to be held at the client, rather than in the server’s limited memory, when the application is slow to consume the data.  Non-browser clients often find themselves in the same position of needing to bound memory used for the connection.

From: Charles 'Buck' Krasic [mailto:[email-masked]]
Sent: Thursday, December 8, 2016 9:58 AM
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: HTTP Mapping: Fixing streams-in-streams

One question I have.  The text refers to the control data streams being exempt from flow control.  In our deployment, headers are exempt from the connection level flow control, but stream level flow control still applies.   Is the full exemption intentional?

Beyond that, I'm interested to know more of the rationale behind flow control.  Tidbits I've heard are not very satisfactory to me, it seems like priorities (which are not fully baked for QUIC yet) would be the more appropriate mechanism.

On Thu, Dec 8, 2016 at 9:52 AM, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
Given some positive feedback and no negative so far, I’m going to go ahead and merge this.  Feedback continues to be welcome.

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Bishop
Sent: Monday, December 5, 2016 1:52 PM
To: Ian Swett <[email-masked]<mailto:[email-masked]>>; Jana Iyengar <[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: HTTP Mapping: Fixing streams-in-streams

--
Charles 'Buck' Krasic | Software Engineer | [email-masked]<mailto:[email-masked]> | +1 (408) 412-1141

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Thu, 8 Dec 2016 12:25:03 -0800

Gah.  My question had a terrible typo. I didn't mean "rationale behind flow
control" but rather "rationale behind the flow control exemption".   Either
way, you answered thanks.  :)

On Thu, Dec 8, 2016 at 12:12 PM, Mike Bishop <[email-masked]>
wrote:

> I actually did update the text to specify “connection-level,” since that’s
> what the transport draft allows the application to do.  In HTTP/2, only
> DATA frames are flow-controlled at all, a subject of some debate in the
> HTTP WG at the time.
>
>
>
> The rationale either way is that payload on the control streams is being
> consumed by the protocol implementation itself, not by something above it,
> so those should flow unimpeded and can be trusted to read and process
> promptly, bugs notwithstanding.  There are other guards against an abusive
> peer:  If the peer opens too many streams they’ll produce a violation at
> the QUIC layer, and you have the option of putting a smaller per-stream
> flow control window to begin with.
>
>
>
> Flow control and priority are related, but serve different purposes.  Flow
> control limits how much unprocessed data I have sitting around, while
> priority dictates how I should allocate a scarce resource (whether that’s
> processing time or bandwidth on the return direction).  A thick client will
> very rarely want to flow-control the server – in practice, they open the
> windows as wide as possible and use priority, as you suggest.  The server,
> on the other hand, wants to carefully bound memory allocations per
> connection – especially where the application actually consuming the data
> isn’t fully reliable from the protocol implementation’s point of view.
> Flow control allows unread data flowing upstream to be held at the client,
> rather than in the server’s limited memory, when the application is slow to
> consume the data.  Non-browser clients often find themselves in the same
> position of needing to bound memory used for the connection.
>
>
>
> *From:* Charles 'Buck' Krasic [mailto:[email-masked]]
> *Sent:* Thursday, December 8, 2016 9:58 AM
> *To:* Mike Bishop <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; Jana Iyengar <[email-masked]>;
> IETF QUIC WG <[email-masked]>
>