Re: Adjusting our spec names

Hi Roberto,

On Sun, Apr 01, 2012 at 06:49:05AM +0200, Roberto Peon wrote:
> 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.

There are basically four things which keep the RTT high :
  - speed of light (intercontinental traffic)
  - time division multiplexing as seen on DSL and Mobile environments
  - queuing (extremely present in mobile environments)
  - serialization (almost null right now)

The former is expensive but is in part addressed by geolocation, though after
that it will not shrink anymore. For instance from here in France :

  $ ping -c 3 www.ucla.edu
  PING www.ucla.edu (169.232.33.224) 56(84) bytes of data.
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=1 ttl=50 time=162 ms
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=2 ttl=50 time=162 ms
  64 bytes from www.ucla.edu (169.232.33.224): icmp_seq=3 ttl=50 time=163 ms

  $ ping -c 3 www.google.com
  PING www.l.google.com (173.194.66.106) 56(84) bytes of data.
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=1 ttl=50 time=10.5 ms
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=2 ttl=50 time=10.6 ms
  64 bytes from we-in-f106.1e100.net (173.194.66.106): icmp_seq=3 ttl=50 time=10.5 ms

The second is still important in 3G networks but is shrinking with increasing
bandwidth, because you always want approximately the same frame size to fit
in a time slot. Right now figures around 30 ms TTI are common in field, yielding
a minimum RTT on empty networks around 60 ms. But recent HSPA updates already
indicate a 2ms TTI. DSL providers have the same issue BTW, and some french ones
are still charging you with an option to reduce your ping time by not padding
small frames !

The third is probably the worst that is experienced on congested networks
everywhere there are speed differences between the two sides, because it's
common to see large buffers there (eg: several megabytes sometimes in 3G),
which is causing a large number of frames to wait. The good point here is
that this queuing time solely depends and the outgoing bandwidth so it is
expected to significantly drop.

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

And it doesn't stand the long range, which is where it would be most helpful.

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

I would be careful when suggesting hardware acceleration. It's already very
hard to get a round trip between CPU and a 10G NIC below 1 microsecond. And to
achieve this, you have to perform active polling using spinlocks (as traders
do). You can't use interrupts anymore otherwise you waste a lot of time. 1
microsecond is short and long at the same time. It's too short to allow you
to do something else (eg: context switching is much more expensive), and it's
very long because if you're waiting for your hardware to compress your frame
for instance, basically you're limited to one million frames per second, which
is lower than what current implementations can achieve on pure software.

You also have the option to share the device between multiple threads but
this involves a painful locking and for having discussed with you, I know
we both shared the same experiences with locking costs which completely
defeat the expected parallelism.

Also, we must keep in mind that the web is currently migrating back to
software only with virtualized environments. This is really not something
to forget !

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

Agreed too, except that for cookies the solution is far from being easy, as
many applications use a number of different context-based cookies, so the
solution is not trivial if we want to guarantee the 1:1 compatibility with
existing applications. That's what you tried to address by compressing
headers and what we tried to address by factorizing them. Maybe other options
exist, I don't know. Perhaps Roy had ideas on the subject when working on
Waka ?

Regards,
Willy

Received on Sunday, 1 April 2012 05:33:59 UTC