- From: Nico Williams <nico@cryptonector.com>
- Date: Fri, 19 Jul 2013 12:04:47 -0500
- To: James M Snell <jasnell@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Mike Belshe <mike@belshe.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
On Fri, Jul 12, 2013 at 11:53 AM, James M Snell <jasnell@gmail.com> 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 --
Received on Friday, 19 July 2013 17:05:12 UTC