Subject: Large Frames, Continuations, Flow Control, and changing HPACK

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 08:55:14 -0700

I would like to propose that we remove the "reference set" from HPACK.

I think that this would help to alleviate many of the issues that are
being brought up on the list w.r.t large header blocks and their
affect on HOL blocking.

By using the "reference set" of headers, the frame boundary and the
header block boundary are tied together. We have also made the
ordering of headers indeterminate leading to the null-separator hack
and made requirements on the receipt of the ":" headers impossible to
enforce requiring possibly complete buffering before basic routing
decisions can be made.

Removing the "reference set" would allow interleaving of HEADERS
frames from different streams. It would remove the need for large
contiguous frames carrying an entire "header block" since the
termination of these blocks is meaningless. Headers could be more
effectively "streamed" and CONTINUATION frames could be dropped from
the spec.

Since HEADERS frames can now be interleaved even if they do not
contain the complete header set, this would also remove the HOL
blocking issue and open up the possibility to flow control headers as
well as data.

- Jeff

---

From: Cory Benfield <[email-masked]>
Date: Tue, 8 Jul 2014 17:02:43 +0100

Note that Kazu Yamamoto posted to the list with implementation data
that suggests that the reference set does not provide a much in the
way of increased compression only last week[1]. Some discussion was
had in that thread, I recommend people read through it before
following up here.

[1]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0149.html

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 08 Jul 2014 16:08:32 +0000

In message <[email-masked]>, Cory Benfield wr
ites:

Relevant to this:  It really worries me that we have no way of
versioning or negotianing the compression algorithm in HTTP/2 ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 9 Jul 2014 01:09:00 +0900

> blocking issue and open up the possibility to flow control headers as
​If I understand the proposal correctly, it still needs contagious
HEADERS+CONTINUATION if >16K header field is sent (assuming the proposal
sticks to 16K frame size).
​For flow control, we still have difficulty to encode (or split) headers in
arbitrary length, dead locking issue still exist.

Best regards,
Tatsuhiro Tsujikawa

---

From: <[email-masked]>
Date: Tue, 8 Jul 2014 16:32:32 +0000

> I would like to propose that we remove the "reference set" from HPACK.

I would be happy to see HPACK simplified. See Kazu's data [1]. The benefit doesn't seem to warrant the complexity, though I recall Google saying they are going to try to collect some data to the contrary.

From Kazu's e-mail:
> - Naive    -- No compression
> - Naive-H  -- Using Huffman only
> - Static   -- Using static table only
> - Static-H -- Using static table and Huffman
> - Linear   -- Using header table
> - Linear-H -- Using header table and Huffman
> - Diff     -- Using header table and reference set
> - Diff-H   -- Using header table, reference set and Huffman

To be clear, are you proposing "Linear-H"??

> [snip]
> and made requirements on the receipt of the ":" headers impossible to enforce
> requiring possibly complete buffering before basic routing decisions can be made.

I suspect the proxy implementers would agree, but I'll let them speak for themselves.

> Removing the "reference set" would allow interleaving of HEADERS frames from
> different streams. ...

Assuming you are proposing "Linear-H" (see question above)...

I think there is still shared state in the 'header table'. Thus although you can interleave HEADERS frames from different streams, you must decompress them in the same order as received.  Furthermore, compression & decompression must be frame-atomic, otherwise multi-threaded implementations will corrupt the shared state in the header table.  Or, am I missing something here?

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0149.html

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 09:39:06 -0700

To be clear, the proposal is:

1) Remove the reference set from HPACK (use "Linear-H")
2) Increase the frame size to 16-bits
3) Allow interleaving of HEADERS frames
4) Remove the "\0" separator hack.

Coupling this with my earlier proposal to add a "SYN_STREAM" header
would also allow us to:

5) Remove CONTINUATION frames entirely
6) Move END_* flags to the last HEADERS frame
7) Flow control HEADERS frames

---

From: Cory Benfield <[email-masked]>
Date: Tue, 8 Jul 2014 17:33:12 +0100

> I would like to propose that we remove the "reference set" from HPACK.

Here's my understanding of the current state of affairs. The following
are, as far as I know, undisputed facts:

1. The reference set is the only part of HPACK that prevents header
frames being interleaved.
2. The reference set is the reason we cannot emit header sets in an
ordered manner, and so are the only reason section 8.1.2.3 of the
HTTP/2 draft exists.
3. The reference set has been shown to provide negligible compression
improvement in _today's_ header fields.
4. No-one has yet provided data to show a realistic data set of header
fields that does show significant improvement with the reference set.

Anecdotally, we can add the following:

5. At least two HPACK implementers (myself and Kazu Yamamoto) have
identified the reference set as the most complicated part of the HPACK
specification.
6. New implementers have complained that HPACK is extremely
complicated to implement from scratch.

With this in mind I'm strongly leaning towards killing the reference
set. I'm a little reluctant to throw away the work I did (having
rewritten my HPACK implementation to fix subtle reference set bugs in
the past). However, it seems clear that we get some big advantages.
Other things worth noting:

- Doing this could allow us to say that the fields relevant to routing
a request MUST come first in the headers block. This will make PHK a
lot happier, as intermediaries can quickly take action and then simply
pass the remaining header data through the compressor to /dev/null
(thereby maintaining header table state). We'd need to work out the
'routing relevant' fields, but that is a reasonable WG action.
- This makes HPACK truly streamable again (emit headers as soon as you
have them).

Assuming no data comes up to invalidate my points 3 and 4, I'm in
favour of this idea. Roberto and Johnny are the only two on the list
I've seen object so far, and Johnny claimed to be getting data. I'd
like to see it.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 09:36:27 -0700

> To be clear, are you proposing "Linear-H"??

Yes, I'm proposing "Linear-H"

> I think there is still shared state in the 'header table'. Thus although you can interleave HEADERS frames from different streams, you must decompress them in the same order as received.  Furthermo…

YES, you can interleave HEADERS frames from different streams but each
frame must be processed in-order.

---

From: Shigeki Ohtsu <[email-masked]>
Date: Wed, 09 Jul 2014 02:11:09 +0900

I'm +1 for this proposal.

I have an issue of handling priority weights in sending multiple HEADERS 
with allocating resorces. I'm using a deficit round-robin and the order 
of sending frames are determined by its size and allocated resources.

With interleaving of HEADERS from diffrent streams, I can adjust and cut 
HEADERS sizes so as to fit their allocated resource and need not care 
their sending orders. Flow control can also be applied to them together 
with DATAs. It would be nice for me to handling priority trees.

Regards,

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 09:29:38 -0700

> If I understand the proposal correctly, it still needs contagious
> For flow control, we still have difficulty to encode (or split) headers in

For a header set larger than 16K compressed, you can divide it into
multiple HEADERS frames and interleave them at will, the last HEADERS
frame needs to have the END_HEADERS flag set.

To send a single header field larger than 16K compressed, we would
need to increase the frame size. I suggest we handle this by
un-reserving the first two bits in the length field so that frames can
be 64K in size. This would put a "hard-limit" on the size of
individual header fields.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Jul 2014 10:40:10 -0700

> frames being interleaved.

That isn't 100% correct.  You need to ensure that an opcode that
references the table doesn't cross a frame boundary, otherwise things
get really messy.

> improvement in _today's_ header fields.

For some sets of data.  The samples we have are for browsing and only
for very short sessions.  For APIs, server-to-server,
XmlHTTPRequest-heavy pages, and similar, my understanding is that a
reference set would be a significant improvement.  I believe that the
reference set would have represented a significant improvement in the
applications I was building when I was at Microsoft.  Sadly, I can't
run the numbers to support this claim.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 10:47:09 -0700

> run the numbers to support this claim.

I am not suggesting we remove the header table, so you can still
encode header fields using the "indexed representation." Yes it is
less efficient than requiring 0 bytes, but in most cases you should be
abel to get away with encoding it in 1 or 2 bytes.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 08 Jul 2014 17:58:00 +0000

In message <[email-masked]>, Martin Thomson w
rites:

>reference set would be a significant improvement.

Isn't this where we add an extension/versioning mechanism for compression
and make a non-state bearing variant the HTTP/2 mandated lowest compliance
level ?

---

From: Johnny Graettinger <[email-masked]>
Date: Tue, 8 Jul 2014 13:56:56 -0400

> abel to get away with encoding it in 1 or 2 bytes.
If you manage cookie crumbs as separate entries, it can be quite a few
indexed opcodes.

Another option is to make "emit the reference set" an explicit signal
(either an opcode, or a flag).

A strategy then might be to toggle off as desired & the emit the reference
set all within the first HEADERS frame, and then follow in subsequent
frames with new literal encodings.

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 8 Jul 2014 17:59:10 +0000

> -----Original Message-----
> From: Jeff Pinner [mailto:[email-masked]]
> Sent: mardi 8 juillet 2014 19:47
> To: Martin Thomson
> Cc: Cory Benfield; HTTP Working Group
> Subject: Re: Large Frames, Continuations, Flow Control, and changing HPACK
> 

An alternative to the reference set would be to add an "indexed range" opcode, that would correspond to several contiguous header fields in the header table.
It would be less efficient than the reference set, as it would need at least 1 or 2 bytes to represent a group of headers where the reference set used none, and would depend on the ordering of the headers in the header table.
However, in specific scenarios such as those pointed at by Martin, a well thought filling of the header table should allow getting significant improvements.

Hervé.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Jul 2014 11:28:07 -0700

Let's take a step back.

Jeff is proposing that we rearchitect the protocol.  Removing the
reference set is a relatively inconsequential part of these changes.
Being able to split header blocks changes the way that the protocol is
structured; it changes the HTTP mapping.

Greg has only proposed that we restructure the "jumbo" frame that we
use for header blocks.

>From that perspective, Greg's proposal is far more a minor tweak.

If the proposed change was to remove the reference set and maybe clean
up some of the consequences of that, like the '\0' hack, then that
would be a relatively small change.  It might also enable alternative
solutions to the issues we're discussing (549, 550 and 551).  But if
we're going to consider a major change like this, it needs to be
better justified.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 09:43:03 -0700

> Coupling this with my earlier proposal to add a "SYN_STREAM" header

* meant a SYN_STREAM frame (see "Another CONTINUATION Proposal" email)

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 12:52:01 -0700

> structured; it changes the HTTP mapping.

"header blocks" and "header block fragments" as defined are a direct
consequence of the reference set. Without the reference set, these
things are meaningless.

> From that perspective, Greg's proposal is far more a minor tweak.

True. It is minor, but it skirts around the underlying issue of HOL blocking.

> we're going to consider a major change like this, it needs to be

The question we pondered at the NYC meeting was "do we need to address
HOL blocking of headers frames."

At the time we decided that we didn't want to change the protocol to
address it. Since then there has been a lot of discussion on the list
on restrictions on HEADERS / CONTINUATION etc. because of that. This
is an attempt to address it directly.

---

From: <[email-masked]>
Date: Tue, 8 Jul 2014 21:22:27 +0000

> On 08 Jul 2014, at 20:48, "[email-masked]" <[email-masked]> wrote:

+1
I think this is a good idea.  (It has a lot of similarities to what I proposed here [1] as an alternative to HPACK.)

When I was writing my proposal I spent a lot of time thinking about compressing runs of keys/values rather than just a single key or value.  The trick is for the decompressor to have some insight (a priori or learned) about the "staticity" of keys and values.  I started doing some research on the http2_samples data set; I'll see if I can dig that up.

Question? Are duplicates allowed in the hpack header set? That would be important for creating different static groups (eg by mime type) where, for example the accept and accept-encoding headers vary by mime type, but user-agent doesn't.

eg consider the following (very) contrived pseudo header table

1 user-agent
2 Mozilla
3 accept
4 text/HTML
5 accept-encoding
6 gzip
7 user-agent
8 Mozilla
9 accept
10 image/JPEG
11 accept-encoding
12 identity

there is a lot of repeat in the table, but the next time I request an HTML page I just need to send a "indexed range" opcode with index 1 and count 6 (two bytes to encode I guess)
But the next time I request an image I just need to send a "indexed range" opcode with index 7 and count 6
Obviously indexing each entry separately would require more bytes on the wire

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1040.html

---

From: <[email-masked]>
Date: Tue, 8 Jul 2014 21:28:17 +0000

> 7) Flow control HEADERS frames

Hi Jeff-

Can you please explain why the SYN_STREAM frame is necessary? It seems to me that just removing the reference set would get rid of the need for CONTINUATION frames since there would no longer be a requirement to process all headers together as one big "jumbo block", just a requirement to process frames in order.

To be short, it seems to me that getting rid of the reference set also solves 5, 6, & 7??

-Keith

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 14:48:09 -0700

> To be short, it seems to me that getting rid of the reference set also solves 5, 6, & 7??

There are two benefits of SYN_STREAM (one is desirable, the other is
necessary given some caveats).

1) One of the design drivers for CONTINUATION over multiple frames
initially was that there were certain fields you didn't want repeated.
Take PUSH_PROMISE as an example where SID = StreamID and PID =
Promised Stream ID. It was preferable to send

PUSH_PROMISE(SUI 2, PID 3) CONTINUATION(SID 2, END_HEADERS)

over

PUSH_PROMISE(SID 2, PID 3) PUSH_PROMISE(SID 2, PID 3, END_HEADERS)

because it avoided having to discuss what to do if the promised id's
were different, i.e.

PUSH_PROMISE(SID 2, PID 3) PUSH_PROMISE(SID 2, PID 1000, END_HEADERS)

There is a similar but less compelling argument for HEADERS if they
have different priority field data.

2) This one is necessary if you want to flow control HEADERS.
Currently HEADERS acts both as a "data" frame and a "control" frame
since it both carries the header block and also opens the stream. If
you flow control HEADERS then it may be that there is not a large
enough window size to send the HEADERS frame. This implicitly blocks
opening the stream as well. In fact there is no way to even signal
that you want to increase the window size (for example by sending
BLOCKED on the stream) because the stream can't be opened.

Introducing SYN_STREAM solves both of these problems:

Separating stream creation from HEADERS means it becomes a "data"
frame, making it possible to flow control without blocking stream
creation. Doing so also removes the race condition between opening the
stream and prioritizing it, so the only thing a HEADERS frame now has
to carry is the header block fragment itself. This allows us to also
remove the header block from PUSH_PROMISE (another control frame that
we don't want to flow control) and replace it by a sequence of HEADERS
frames, removing the need for text on what to do if the control fields
(like promised stream id) vary within the sequence.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 8 Jul 2014 15:01:20 -0700

> 1) Remove the reference set from HPACK (use "Linear-H")

+1; Kazu's data convinces me entirely.

> 2) Increase the frame size to 16-bits

+1 to increase the size.  I would support going larger; the artificial
limits never provided value in SPDY nor H2.  I liked Greg's proposal
generally.

> 4) Remove the "\0" separator hack.

+1; these were hacks unresolved due to the global compressor.

> 5) Remove CONTINUATION frames entirely

+1; this makes things much simpler.

> 6) Move END_* flags to the last HEADERS frame

+1; makes things simpler.

> 7) Flow control HEADERS frames

+1;  this is just simpler too.

Mike

---

From: Jason Greene <[email-masked]>
Date: Tue, 8 Jul 2014 17:11:31 -0500

On Jul 8, 2014, at 5:01 PM, Mike Belshe <[email-masked]> wrote:

> +1 to increase the size.  I would support going larger; the artificial limits never provided value in SPDY nor H2.  I liked Greg's proposal generally.
>  

Wow, are we actually approaching consensus? :)

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Nicholas Hurley <[email-masked]>
Date: Tue, 8 Jul 2014 15:44:09 -0700

While I'm a fan of removing the reference set (which has come up multiple
times before), I'm not a big fan of the rest of the changes proposed -
they're much more invasive than Greg's proposal. Being required to split
the HPACK encoding at JUST the right point to fit in a 64k frame is a much
uglier change than asking "I've generated more than 16k of headers. Does my
peer support a frame size that this fits in?" Given a choice between the
two (and without a choice of "keep the status quo" - which is still far and
away my preference), I would much rather have a simple setting with jumbo
frames (Greg, et al's proposal).

So, even though we aren't voting, I'll give this my proverbial -1 and
change my -1 on Greg's proposal to a +/-0 if we could keep the status quo,
or a strong +1 if we've come to consensus on dispensing with the status
quo. That comes with a couple caveats - I would want to see a larger
minimum for the max frame size (256 is laughably small, and is a really
good way to shoot oneself in the foot really easily - I propose 4k, based
on the numbers I see in Firefox's telemetry for compressed header size),
and I don't like the dynamic changing of frame size on a per-stream basis
(which feels both too invasive, and WAY too easy to get wrong).

--
Peace,
  -Nick

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 15:48:55 -0700

> .... Being required to split the
> HPACK encoding at JUST the right point to fit in a 64k frame is a much
> peer support a frame size that this fits in?"

This isn't really an accurate description. Without the reference set,
HPACK is now streaming so the decision becomes:

1) Encode this header into x bytes.
2) Is x > 64k? This will never work any more, ABORT!
3) Do x more bytes fit into this frame?
4a) If yes, add x bytes and increase frame length.
4b) If no, flush this frame and start a new one.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 15:53:50 -0700

> That, however *requires* a streaming implementation, which while possible,
> is not required by HPACK in its current state.

Very true.

---

From: Nicholas Hurley <[email-masked]>
Date: Tue, 8 Jul 2014 15:53:01 -0700

--
Peace,
  -Nick

---

From: Roberto Peon <[email-masked]>
Date: Tue, 8 Jul 2014 16:01:27 -0700

Note that we can still have a reference set and be streaming-- it just
requires that emitting from the reference set is an explicit
opcode/flag/bit.
This would mean that encoders wouldn't need to know about the reference set
if they didn't care to, which would be nice.

-=R

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 9 Jul 2014 09:20:03 +1000

> Wow, are we actually approaching consensus? :)

I think bifurcation is a word that comes to mind  more than consensus :(

CONTINUATIONs are just emergent design uglyness that resulted from the
inability to split headers and small frames.   Having large frames doesn't
solve the base issue, but does get rid of much of the design uglyness that
resulted, plus it supports some tuning/efficiencies of data transfer as
well.  So I really hope we can reach consensus on that part soon.

Jeff proposal is a much bigger step towards a h2 that would have a pure
framing layer, over which http, websocket etc. semantics can be layered.
But it is not a complete step.  Removing the Reference Set would allow
interleaving, but it would still have shared state, so the order of
decompressing is still fixed and thus header encoding and HTTP semantics is
still effectively part of the framing layer.

So I'm wondering if such a drastic step were to be contemplated, if it
would just be better to ask to be rechartered to be tasked with designing a
general web framing layer that could support multiple web protocols - and
then design that fully properly rather than just cut off the bits of h2-13
that don't look like it.     Ie the current design is suffering as it has
been asked only to consider http.   If we were asked to consider http,
websocket and other future protocols, then the outcome would be different

So I think that HPACK as is, is a little complex but does meet our current
charter.  I'm not so sure our charter is correct and if it isn't then Jeffs
proposal probably points in the direction to go.

cheers

PS> But under the current charter, I certainly wouldn't weep if the
ReferenceSet was dropped and headers flow controlled.

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 8 Jul 2014 16:34:11 -0700

There are two HOL blocking issues w.r.t. headers:
  1) HOL blocking because you can't send data frames while headers are
being transmitted.
  2) HOL blocking because you can't create other new streams while headers
are being transmitted.

Removing the reference set doesn't change either of these.

#1 occurs because of an artificial restriction added to the spec for the
sake of implementation simplicity.
We could remove tomorrow by allowing data frames to interleave with
headers/continuation.
#2 is the big(ger) issue.

The easiest solution to #2 is to send small headers, which is what commonly
takes place today.
Assuming that large headers are being sent, however,

Even without a reference set, anything that modifies or references state
places an ordering requirement on header data.
Getting rid of the reference set reduces HPACK code complexity for decoders
and encoders slightly, and that is about it as far as properties of that
change.
Making emission of the reference set explicit (instead implicit at the end
of the header block) helps to reduce encoder complexity somewhat, but the
opcode-frame-boundary-crossing issues still exist.

Jeff's proposal of separating SYN_STREAM is meant to help address #2.
I don't know if that would work, however, since knowing what the stream is
about or addressed to requires the headers, which in turn means that stream
creation is always tied to headers anyway... and you end up HOL blocking on
'em at the receiver, though not necessarily on the wire.
-=R

On Tue, Jul 8, 2014 at 2:28 PM, <[email-masked]> wrote:

> Can you please explain why the SYN_STREAM frame is necessary? It seems to
> me that just removing the reference set would get rid of the need for
> CONTINUATION frames since there would no longer be a requirement to process
> all headers together as one big "jumbo block", just a requirement to
> process frames in order.
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>
>

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 17:17:57 -0700

> requires that emitting from the reference set is an explicit

Very true. But for reference sets to be really managed well by proxies
we need multiple reference sets to group headers from the same initial
stream together. The current design compromises on that complexity and
IMHO does not deliver enough benefit to be worth it.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 8 Jul 2014 17:22:21 -0700

> IMHO does not deliver enough benefit to be worth it.

* same initial connection, sry

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Jul 2014 17:33:39 -0700

> limits never provided value in SPDY nor H2.  I liked Greg's proposal

Just chiming in to note that this statement is factually incorrect, since
Patrick identified several instances where serialization latency of large
DATA frames was substantial. You can subjectively say this is little value,
but saying it has no value is simply false.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 8 Jul 2014 17:50:04 -0700

> but saying it has no value is simply false.

We all know that depending on what network/configuration/content you're
rendering you'll see different results between 4kb, 12kb, and 16kb.  These
tests go back to the origin of SPDY.   What I was trying to say is that you
can have a larger maximum size and yet use a smaller size to get better
performance if that suits you.  So the "little value" means that it doesn't
inhibit using well suited frame sizes.  Conversely, if you are running a
case where larger frames would help, you cannot go beyond an artificially
low maximum.

I believe most implementations will voluntarily use smaller sizes for
performance reasons without having to put a hard coded constant in the
frame size.  We certainly did this in the early spdy implementations, and
it worked.  Since it was working, clearly the artificially smaller frame
size is optional - you can still achieve good performance without it, and
that is why I claim it has minimal value.

Mike

---

From: Erik Nygren <[email-masked]>
Date: Tue, 8 Jul 2014 21:11:25 -0400

Would getting rid of the reference set also allow us to move the static
table back to a fixed position?
That also seemed like it would have value for some implementations and
use-cases
based on the previous discussion but was problematic as long as we had the
reference set, as I remember it.

        Erik

On Tue, Jul 8, 2014 at 7:34 PM, Roberto Peon <[email-masked]> wrote:

> The easiest solution to #2 is to send small headers, which is what
> commonly takes place today.
> Getting rid of the reference set reduces HPACK code complexity for
> decoders and encoders slightly, and that is about it as far as properties
> of that change.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 9 Jul 2014 10:13:19 +0900

> 4b) If no, flush this frame and start a new one.

How does this interact with flow control?  If we want to 64K header and
peer advertised smaller winfow size we just stuck.  Generally I don't think
flow  control does work well with headers.

Best regards,
Tatsuhiro Tsujikawa

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 8 Jul 2014 18:17:14 -0700

> that is why I claim it has minimal value.

This is totally a valid point of view, but I'm more skeptical than you are
about the quality of implementations. I submit as evidence that both
Apache's mod_ssl and nginx's openssl usage did/do not use small TLS record
sizes despite the far more drastic impact on latency. For example, despite
web perf advocates like yourself publicizing TLS record size issues, nginx
still uses 16kb records by default:
http://lxr.nginx.org/source/src/event/ngx_event_openssl.h#0109.

Maybe the landscape has changed now though and more people care about web
performance and will notice these issues. But Patrick showed us that a
number of SPDY implementations, which theoretically implement for web
performance reasons and thus should be paying attention to this, still get
this wrong.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 9 Jul 2014 11:39:02 +1000

Everyone,

I think we're getting very close to consensus on Greg (et al)'s proposal, so clarity here would be appreciated.

Please be specific about what you like about this proposal -- 

a) Getting rid of the reference set (Jeff's "1", maybe "4") is a good idea, and complementary to Greg (et al)'s proposal
b) This complete set of changes is a preferable alternative to Greg (et al)'s proposal
c) Don't know, need to talk more. 

Thanks,

--
Mark Nottingham   https://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 8 Jul 2014 19:20:07 -0700

Having not been a fan of the reference set from the onset (I argued
*long ago* that it should just go away) I'm definitely +1 on Jeff's
proposal. (of course, I'd MUCH rather see *stateful* header
compression get tossed out entirely).

Also..

  +1 on Greg's proposal re: larger frame sizes and dropping
CONTINUATION entirely.
  +1 on PHK's proposal to allow negotiation of header compression scheme

I would also take a moment to reflect on the fact that HPACK is not
actually required for HTTP/2 to meet it's chartered goals. I know
there are arguments that say that header compression makes
multiplexing better, but that doesn't mean that (a) it has to be HPACK
and (b) that it has to be stateful. The overwhelming majority of the
problems currently being discussed simply vanish if we eliminate the
idea that header transmission could, in any way, modify connection
state.

- James

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 9 Jul 2014 12:25:50 +1000

Mark

I'm definitely not b)

While Jeff's proposal does include a larger frame size, it is not large
enough nor does it have the settings limits that I think are required to
ensure that usage of large frames in consensual between peers.   Note that
Jeff's proposal could easily be amended to include large frames and
settings, but I'd prefer to see that considered as orthogonal - ie the core
of Jeff's proposal works equally well with 14, 16 or 31 bit length field.

Then I can't really decide between a) and c).    Jeffs proposal does have
good ideas in it, but see my previous emails about it perhaps not going far
enough, but to go further we'd need to reconsider the charter.  Which means
I can live with both.

cheers

On 9 July 2014 11:39, Mark Nottingham <[email-masked]> wrote:

> a) Getting rid of the reference set (Jeff's "1", maybe "4") is a good
> idea, and complementary to Greg (et al)'s proposal

---

From: James M Snell <[email-masked]>
Date: Tue, 8 Jul 2014 19:35:57 -0700

Apparently I wasn't clear enough... I'm +1 on having a >16k header frame
size but have no particular number in mind. Greg's proposal re: frame size
seems reasonable. I'm +1 on Jeff's proposal to drop the reference set, but
do not believe it goes far enough.

- James
On Jul 8, 2014 7:20 PM, "James M Snell" <[email-masked]> wrote:

> > I think we're getting very close to consensus on Greg (et al)'s
> proposal, so clarity here would be appreciated.
> >

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 09 Jul 2014 15:03:17 +1200

> c) Don't know, need to talk more.

a and c.

I believe the reference set benefits are long-term and we wont be able 
to know whether the complexity is worth it until much of the ecosystem 
has been updated to HTTP/2 and implemented with some fairly smart 
encoding algorithms.

The proposal from Greg (et al) makes the frame encoding/decoding much 
more atomic which in turn reduces the necessity of removing reference 
set. There may be an alternative we can find on top of Gregs proposal 
that leaves those long term benefits with less complexity than present 
right now.

Someone may also come up with a better way to reduce repeated headers, 
or enable HPACK algorithm upgrades within h2 framing.

Amos

PS. I understand from discussions here that HPACK draft contains several 
completely separate encoding schemes/profiles but as written it is 
unclear which encoding operations apply to each profile. Perphase some 
editorial clarification to point implementers at which particular 
sub-set(s) of encoding actions make up each profile would help with the 
arguments about HPACK complexity.

> Thanks,
> 
> On 9 Jul 2014, at 2:39 am, Jeff Pinner wrote:
>

---

From: Cory Benfield <[email-masked]>
Date: Wed, 9 Jul 2014 08:12:45 +0100

> c) Don't know, need to talk more.

I'm at a). I won't miss the reference set. If we're genuinely worried
about whether the loss of the reference set is a time-bomb, I suggest
we consider PHK's negotiation of header compression proposal.

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 13:03:22 +0000

> c) Don't know, need to talk more.

Yes on 'a)'.

I think 'b)' would be direction if we different charter (as Greg outlined here [1]) to make the framing layer more generic.

-keith

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/0583.html