Subject: encoding and other h2 extensions

From: Matthew Kerwin <[email-masked]>
Date: Fri, 21 Nov 2014 17:33:04 +1000

Since things seem to be settling down now, with most changes seemingly
editorial, and most implementations presumably moving towards debug (rather
than implement) mode, I feel like once again broaching the topic of encoded
(read: compressed) DATA frames.

The current version of my "encoded data" draft is <
http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-03>

It includes a reference to another idea I had <
http://tools.ietf.org/html/draft-kerwin-http2-segments-01> to which I'm not
exactly married -- I'd be happy to keep it, roll it into the encoded-data
draft, or just drop it.

My question is: is anyone else interested in pursuing/implementing encoded
data? Do you think it's worthwhile me continuing to plug away at it?

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 22 Nov 2014 05:37:08 +1300

On 21/11/2014 8:33 p.m., Matthew Kerwin wrote:
> Since things seem to be settling down now, with most changes
> seemingly editorial, and most implementations presumably moving
> towards debug (rather than implement) mode, I feel like once again
> broaching the topic of encoded (read: compressed) DATA frames.
> 
> http://tools.ietf.org/html/draft-kerwin-http2-segments-01> to which
> I'm not exactly married -- I'd be happy to keep it, roll it into
> the encoded-data draft, or just drop it.
> 
> My question is: is anyone else interested in pursuing/implementing
> encoded data? Do you think it's worthwhile me continuing to plug
> away at it?
> 

I am intending to implement encoded data or some close variant for
Squid. Just procrastinating a bit on the basic h2 parts.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 21 Nov 2014 17:25:52 +0000

--------

>Squid. Just procrastinating a bit on the basic h2 parts.

Can we please not add another Chernobyl option ?

We don't need the choice between Compress+Gzip+Zlib, just pick
one of them and the world will be a better place.

There are no credible schenarios under which a HTTP/2 implementation
cannot implement *any* of those three, but it is utterly stupid
to require them to implement all three, just to be sure to interop.

If somebody comes up with a compression which is significantly
better than gzip, for this purpose, then *that* could be added
to the list.

-- 
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: Matthew Kerwin <[email-masked]>
Date: Sat, 22 Nov 2014 09:31:55 +1000

On 22 November 2014 03:25, Poul-Henning Kamp <[email-masked]> wrote:

> ​​
> ​​
> ​<...>
​So I guess your preference is gzip?​

​​
> ​
To my mind, the initial registry is of secondary importance to getting the
machinery right in the first place. If the extension mechanism itself
works, and issues like fragmentation are significantly addressed, *then*
I'd want to focus on seeding the registry (in a way that will promote
adoption and interop). This list was pulled straight from RFC 7230 S4.2,
plus a little splash of paint, because that involved the least thought on
my part.

I have no problem with reducing it to just gzip, say. I've also had a
request for LZ4, which is a damn sight faster than LZ77, if a bit weaker on
the compression ratio. The problem with that one is that it doesn't have
gzip's ubiquity, and I don't know how to reference things that don't have
solid specs (at least more solid than a blog post[1]).

​But as you say, the encodings themselves ​
​
​are​ almost trivial; I want to get the extension part right first.

​[1]: http://fastcompression.blogspot.com.au/2011/05/lz4-explained.html​

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Nov 2014 14:44:34 -1000

On 21 November 2014 13:31, Matthew Kerwin <[email-masked]> wrote:
> machinery right in the first place. If the extension mechanism itself works,
> and issues like fragmentation are significantly addressed, *then* I'd want
> to focus on seeding the registry (in a way that will promote adoption and
> interop). This list was pulled straight from RFC 7230 S4.2, plus a little
> splash of paint, because that involved the least thought on my part.

There is another way of tackling the problem, which might be better.
If your proposal requires an extension, then make it a simple
extension: if negotiated, then X is used (be that gzip or whatever you
choose).  If a new thing comes along, then that is a completely
different extension that is incompatible with the first (you can't
have both).  That way, no registry or extension mechanism other than
the one you rely on.  Registries are expensive.

(Not an endorsement, just an observation.)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 22 Nov 2014 06:02:21 +0000

--------
In message <[email-masked]>, Matthew Kerwin writes:

>So I guess your preference is gzip?

Yes, because it comes with a command line tool whereas libz doesn't.

The extra few bytes of header is worth that IMO.

>request for LZ4, 

Now that I could possibly understand, but compress ?  No.

You may want to think about making the first one, which ever one you
choose mandatory to ensure interop.