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

Re: Framing and control-frame continuations

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 06 Feb 2013 14:19:13 +0000
To: Roberto Peon <grmocg@gmail.com>
cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <23161.1360160353@critter.freebsd.dk>
Content-Type: text/plain; charset=ISO-8859-1
In message <CAP+FsNf1s3CV5eMzfmhFa2C8qf04uef732s690odE3uTcNTkGQ@mail.gmail.com>
, Roberto Peon writes:

>I know from past experience that one can fill up a 10GE pipe with very
>small SPDY frames (1XXmillion 1 byte payloads)  when done correctly on
>today's hardware, without using up all cores (though, to be fair it comes
>close). This is pretty much a worst-case scenario.

And where is the 10-20 years head-room in that ?

Remember:  Cores are unlikely to become faster, you'll just get more
and more of them.  Media on the other hand, seems to keep getting faster.

>I've found that the amount of cores one uses to output a certain amount of
>bandwidth is far more dependent on the the NIC kernel drivers and NIC
>hardware than anything else.

And you can take it from me, with my kernel-developer hat on, that
it is an issue which is being worked on aggressively, so HTTP/2
would be stupid to assume that the kernel guys don't improve this

>I currently can't imagine what a 1T network architecture will look like
>when going into a single machine.

What you can or cannot imagine is not really a relevant yard-stick.

And whats more, some of use don't need to imagine, I know people
who _have_ (almost working) 1Tbit interfaces into a single machine

There is absolutely no sane reason to limit HTTP/2 frames to a puny
64Kbyte at this time and date:  PDP-11 compatibility is not really
an issue any more.

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.
Received on Wednesday, 6 February 2013 14:19:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC