Efficiency and statefulness in conflict (Re: HTTP router point-of-view concerns)

[Nico Williams <[e-mail]>]

On Fri, Jul 12, 2013 at 11:53 AM, James M Snell <[e-mail]> wrote:
> Most of the feedback that I've seen around header compression can be
> summarized as:
>
>   Sending less data on the wire... Good.
>   Less latency... Good.
>   More efficiency... Good.

Efficiency is actually a trade-off.  CPU vs. wire bandwidth use efficiency.

This might be a good time to point out how CPU and RAM bandwidth have
not been growing as quickly as wire bandwidth: if that keeps up then
compression is a waste of resources.  OTOH, if we can rely on massive
horizontal scaling in CPUs to cheaply take up the slack then that
might not be a problem, but that's still in the future.

IMO compression needs to be a) OPTIONAL, b) default to OFF.  If for a
particular client/server (client/proxy, proxy/proxy, proxy/server)
pair it pays to compress, then let them.

>   Less visibility in the protocol... Bad.

Meh.  That's what tools are for.

>   Complicated implementation... Bad.

Sure.

>   Introducing statefulness in the protocol... Bad.

Statefulness is bad if the efficiency trade-off isn't worth it.  To me
"more efficiency... good" and "statefulness... bad" are in conflict.
That conflict needs resolution.

> Where I come down on this is simple:
>
> Yes, we need a way of encoding headers more efficiently in HTTP/2

You can do this without stateful compression: just use a more
efficient encoding (one-time static compression, if you wish).  We had
this discussion a while back.

Nico
--