W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Nico Williams <nico@cryptonector.com>
Date: Fri, 19 Jul 2013 12:04:47 -0500
Message-ID: <CAK3OfOhSs13zLaCFpqWvyOPZSBof0yMpb3bM3M4rK+c8n=omkQ@mail.gmail.com>
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.


>   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.

Received on Friday, 19 July 2013 17:05:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC