Re: delta encoding and state management

I'm very comfortable optimizing for poor bw:latency ratios above other
considerations. There's no other important reason to rev the protocol.



On Wed, Jan 23, 2013 at 8:19 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <
> CAOdDvNoOnscRCA54n07Suxe9UQieq32SkwvMxNnEdSnK94s_PA@mail.gmail.com>
> , Patrick McManus writes:
>
> >> As I said, I think that if the state itself is never larger than a
> request
> >> and substitutes for the request, it's not that big of a deal.
> >
> >honestly, the trend in ram prices [...]
>
> I think both of your perspectives are too near-sighted here.
>
> The protocol you should be working on should be the one which
> still works when most middle-class homes, not only in the western
> world, but also in India and China, have fibre to the home at
> speeds of 1Gbit/sec and above.
>
> In that world, a major piece of global news, be it a naked breast,
> an geophysical event or a shot politician, is going to make the
> traffic spikes we have seen until now look tame.
>
> HTTP is a very assymetric usage protocol, and therefore any amount
> of state that the server _has to_ retain for a client must justify
> it's existence, byte for byte, against the scenario where 10% of
> the world want to access the same URL.
>
> HTTP/1 allows you to deliver content without committing any per-client
> state, beyond the TCP socket, and that is not a "degraded mode",
> that is the default mode.
>
> If your HTTP/2 proposal cannot do that, you're working on the wrong
> protocol.
>
> Poul-Henning
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>