Subject: Header Compression...

From: James M Snell <[email-masked]>
Date: Tue, 6 Aug 2013 09:43:05 -0700

While I was, unfortunately, unable to get my http/2 client
implementation ready in time for the berlin interop testing, I was
able to take time over the last month to dig into the header
compression implementation in greater detail and I would have to say
that while I agree that the current design offers a great compression
profile and is technically sound for what it offers, I am definitely
-1 on adopting the currently defined scheme as is without making
significant changes. There are a number of reasons for this position
that I've talked about a few times already so I won't get into those
again.

For one, as my experimentation with the Stored Header Encoding and
typed codecs demonstrates, it is possible to achieve good compression
ratios using a much less complicated mechanism that is more "routing
friendly", more streaming-based, has better support for ordered values
(see Julian's recent comments on multi-valued header fields), has
stronger memory consumption constraints and is easier to implement.
Granted, we end up sending a few more bytes over the wire but that's
OK, IMHO. Sending those few additional bytes is far better, in my
opinion, than significantly increasing the implementation complexity
of the protocol through seemingly endless premature optimization
(repeat after me, "Perfect is the enemy of good"...)

In my opinion, the differential encoding and the reference set both
ought to go away; the more efficient typed codecs ought to be
introduced; and the header table ought to be limited to 256 storage
slots so that index positions never require more than a single octet
to represent on the wire. We can keep incremental and substitution
indexing... In other words, some variation of what I have proposed in
http://tools.ietf.org/html/draft-snell-httpbis-bohe-11.

Yes, I fully recognize that this approach ends up sending more bits
over the wire on average, but that's ok. There are other approaches we
can take (e.g. better sessions) that can address that gap.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 6 Aug 2013 11:49:47 -0700

Here is an updated version of the Stored Header Encoding proposal that
includes the Typed Codecs.

http://www.ietf.org/id/draft-snell-httpbis-bohe-12.txt

I want to "officially" get this on the table as a proposed alternative
to the current header compression mechanism.

This really exists in two parts:

1. The type codecs (which can live equally well in the current header
compression mechanism)
2. The alternative header block encoding.

---

From: James M Snell <[email-masked]>
Date: Wed, 14 Aug 2013 12:33:24 -0700

Based on feedback I have received offlist and implementation
experience, I have made a few additional modifications to the proposed
alternative "Stored Header Encoding" draft.

  http://www.ietf.org/id/draft-snell-httpbis-bohe-13.txt

This offers a significantly less-complex alternative to the current
Header Compression mechanism at the cost of a few additional bits on
the wire. The changes I have made to this draft include combining
"Literal Replacement" and "Literal Incremental" into a single
representation. I also made a few editorial improvements here and
there.

As always, comments and feedback are definitely welcome.

- James

---

From: "Ludin, Stephen" <[email-masked]>
Date: Wed, 14 Aug 2013 13:45:26 -0600

I took a swing at pulling together a HTTP/2.0 dissector for wireshark:

https://github.com/sludin/http2-wireshark

It does the basics a this point but there is certainly room for
improvement.  If anyone has good wireshark dev experience and wants to
contribute you are extremely welcome.

Enjoy,

-stephen

---

From: Roberto Peon <[email-masked]>
Date: Wed, 14 Aug 2013 13:11:51 -0700

Awesome!
-=R

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 14 Aug 2013 22:15:09 +0200

+hasan who has worked on the SPDY dissector which should look somewhat
similar. Perhaps there's room for collaboration?

On Wed, Aug 14, 2013 at 10:11 PM, Roberto Peon <[email-masked]> wrote:

> Awesome!
> -=R
>
>
> On Wed, Aug 14, 2013 at 12:45 PM, Ludin, Stephen <[email-masked]>wrote:
>

---

From: "Ludin, Stephen" <[email-masked]>
Date: Wed, 14 Aug 2013 15:21:29 -0500

Indeed.  Hasan and I discussed this at the interim, though it was late into the dinner so I will not be held accountable to recalling the details.  In essence I remember committing to taking a swag at it and then seeing where things could be combined.

-stephen

From: "William Chan (陈智昌)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 14, 2013 1:15 PM
To: Roberto Peon <[email-masked]<mailto:[email-masked]>>, Hasan Khalil <[email-masked]<mailto:[email-masked]>>
Cc: Stephen Ludin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: HTTP/2.0 wireshark dissector

+hasan who has worked on the SPDY dissector which should look somewhat similar. Perhaps there's room for collaboration?

On Wed, Aug 14, 2013 at 10:11 PM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:
Awesome!
-=R

On Wed, Aug 14, 2013 at 12:45 PM, Ludin, Stephen <[email-masked]<mailto:[email-masked]>> wrote:
I took a swing at pulling together a HTTP/2.0 dissector for wireshark:

Enjoy,

-stephen

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 14 Aug 2013 22:29:14 +0200

Awesome!
On Aug 14, 2013 10:22 PM, "Ludin, Stephen" <[email-masked]> wrote:

> Indeed.  Hasan and I discussed this at the interim, though it was late
> into the dinner so I will not be held accountable to recalling the details.
>  In essence I remember committing to taking a swag at it and then seeing
> where things could be combined.
>
> -stephen
>
> From: "William Chan (陈智昌)" <[email-masked]>
> To: Roberto Peon <[email-masked]>, Hasan Khalil <[email-masked]>
> Cc: Stephen Ludin <[email-masked]>, "[email-masked]" <
> [email-masked]>

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 14 Aug 2013 13:33:40 -0700

http://who-is-awesome.com/who-is-awesome.jpg

---

From: Michael Sweet <[email-masked]>
Date: Thu, 15 Aug 2013 15:30:43 -0400

James,

Aside from still having concerns about the timestamp encoding, it isn't clear from the draft how you would update an existing index's value but leave the name unchanged, e.g., sending a new :path header.

>From prior discussions (and I admit I don't know if I am confusing your proposal with the other header compression) I seem to remember that sending an empty name would do the trick???

For example, indexed literal for ":path=/" encoding for slot 3 would be:

    0x40 0x03 0x05 ":path" 0x01 "/"

and then for a follow-up request to get /favicon.ico you'd use:

    0x40 0x03 0x00 0x0c "/favicon.ico"

Or am I remembering wrong?

>>> can take (e.g. better sessions) that can address that gap.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: James M Snell <[email-masked]>
Date: Thu, 15 Aug 2013 12:55:15 -0700

> Or am I remembering wrong?

Look at the Literal (name,value) Representation in Section 3.1... I've
adopted the same mechanism here as used in the current Header
compression draft... The name portion can be encoded literally as a
sequence of ASCII octets or as an index reference to another stored
header with the same name.

So using your example, it would be:

0x40 0x03 0x00 0x03 0x0c ...

Where...

  0x40 == indexed literal group with 1 entry
  0x03 == the index position being assigned
  0x00 == UTF8 value with indexed name reference
  0x03 == the index of the existing entry whose name we are re-using
  0x0c == the length of the value
  ...  == the remaining octets

- James