Re: Adjusting our spec names

On Sat, Mar 31, 2012 at 1:17 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

>
> Can I ask a really fundamental question:
>
> How long do we expect HTTP/2.0 to last ?
>
> It sounds a lot to me like people are busy trying to solve the last
> remaining problems with yesterdays HTTP/1.1, rather than trying to
> build a solid foundation for the next 10-ish years of HTTP.
>
> If you look at what various labs are churning out of wired/optical/wireless
> technologies, five years from now, we'll be talking a quite different
> environment than now, with respect to bandwidth, RTT and spikiness.
>

I can believe there is a different world ahead w.r.t. bandwidth, but seeing
massive RTT decreases would be surprising. Even if switching delay is
reduced to zero, speed-of-light still dominates the RTT costs. We could go
back to microwave to get some of the RTT costs down (I understand that some
of the real-time traders do this), but it seems unlikely to offer the same
bandwidth (who knows?). In any case, we're looking at something like an
improvement from 2/3rds speed-of-light plus epsilon to 1/1 speed-of-light
at best.


>
> 10 years from now, something big will happen, and the big news-sites
> will be expected to deliver 1Tbit/sec sustained while everybody and
> his goat follows the news in real time.  Ask cnn.com what 9/11 felt
> like, and move it up three orders of magnitude or more.
>
> None of the proposals we have seen so far is anywhere near being
> feasible in such a context.
>

What is your basis for this statement? After all, your argument about
technology improvements in the future cuts both ways:  Are you assuming the
presence or lack of presence of hardware acceleration for any of the
features that may be required for any of the things required in any of the
proposal?


> We simply have to do something about stuff like the convoluted and
> expensive generation and parsing of Date: headers.
>

I completely agree on that one. Arguably that could be said for cookies and
the URL, etc. as well...

As for your first point... are you suggesting that we develop something
other than HTTP/2.0?
I'd suggest that we should design so that this is possible, but... I think
that (charter aside) things which are fundamentally different from what
HTTP does today would be biting off more than we can chew right now :/

-=R


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