Subject: HTTP/2 Expression of luke-warm interest: Varnish

From: Poul-Henning Kamp <[email-masked]>
Date: Thu, 12 Jul 2012 23:48:20 +0000

This is Varnish' response to the call for expression of interest
in HTTP/2[1].

Varnish
-------

Presently Varnish[2] only implements a subset of HTTP/1.1 consistent
with its hybrid/dual "http-server" / "http-proxy" role.

I cannot at this point say much about what Varnish will or will
not implement protocol wise in the future.

Our general policy is to only add protocols if we can do a better
job than the alternative, which is why we have not implemented HTTPS
for instance.

Should the outcome of the HTTP/2.0 effort result in a protocol which
gains traction, Varnish will probably implement it, but we are
unlikely to become an early implementation, given the current
proposals at the table.

Why I'm not impressed
---------------------

I have read all, and participated in one, of the three proposals
presently on the table.

Overall, I find all three proposals are focused on solving yesteryears
problems, rather than on creating a protocol that stands a chance
to last us the next 20 years.

Each proposal comes out of a particular "camp" and therefore
all seem to suffer a certain amount from tunnel-vision.

It is my considered opinion that none of the proposals have what
it will take to replace HTTP/1.1 in practice.

What if they made a new protocol, and nobody used it ?
------------------------------------------------------

We have learned, painfully, that an IPv6 which is only marginally
better than IPv4 and which offers no tangible benefit for the people
who have the cost/trouble of the upgrade, does not penetrate the
network on its own, and barely even on goverments mandate.

We have also learned that a protocol which delivers the goods can
replace all competition in virtually no time.

See for instance how SSH replaced TELNET, REXEC, RSH, SUPDUP, and
to a large extent KERBEROS, in a matter of a few years.

Or I might add, how HTTP replaced GOPHER[3].

HTTP/1.1 is arguably in the top-five most used protocols, after
IP, TCP, UDP and, sadly, ICMP, and therefore coming up with a
replacement should be approached humbly.

Beating HTTP/1.1
----------------

Fortunately, there are many ways to improve over HTTP/1.1, which
lacks support for several widely used features, and sports many
trouble-causing weeds, both of which are ripe for HTTP/2.0 to pounce
on.

Most notably HTTP/1.1 lacks a working session/endpoint-identity
facility, a shortcoming which people have pasted over with the
ill-conceived Cookie hack.

Cookies are, as the EU commision correctly noted, fundamentally
flawed, because they store potentially sensitive information on
whatever computer the user happens to use, and as a result of various
abuses and incompetences, EU felt compelled to legislate a "notice
and announce" policy for HTTP-cookies.

But it doesn't stop there:  The information stored in cookies have
potentialiiy very high value for the HTTP server, and because the
server has no control over the integrity of the storage, we are now
seing cookies being crypto-signed, to prevent forgeries.

The term "bass ackwards" comes to mind.

Cookies are also one of the main wasters of bandwidth, disabling
caching by default, sending lots of cookies were they are are not
needed, which made many sites register separate domains for image
content, to "save" bandwidth by avoiding cookies.

The term "not really helping" also comes to mind.

In my view, HTTP/2.0 should kill Cookies as a concept, and replace
it with a session/identity facility, which makes it easier to
do things right with HTTP/2.0 than with HTTP/1.1.

Being able to be "automatically in compliance" by using HTTP/2.0
no matter how big dick-heads your advertisers are or how incompetent
your web-developers are, would be a big selling point for HTTP/2.0
over HTTP/1.1.

However, as I read them, none of the three proposals try to address,
much less remedy, this situation, nor for that matter any of the
many other issues or troubles with HTTP/1.x.

What's even worse, they are all additive proposals, which add a
new layer of complexity without removing any of the old complexity
from the protocol.

My conclusion is that HTTP/2.0 is really just a grandiose name for
HTTP/1.2:  An attempt to smoothe out some sharp corners, to save a
bit of bandwidth, but not get anywhere near all the architectural
problems of HTTP/1.1 and to preserve faithfully its heritage of
badly thought out sedimentary hacks.

And therefore, I don't see much chance that the current crop of
HTTP/2.0 proposals will fare significantly better than IPv6 with
respect to adoption.

HTTP Routers
------------

One particular hot-spot in the HTTP world these days is the
"load-balancer" or as I prefer to call it, the "HTTP router".

These boxes sit at the DNS resolved IP numbers and distributes
client requests to a farm of HTTP servers, based on simple criteria
such as "Host:", URI patterns and/or server availability, sometimes
with an added twist of geo-location[4].

HTTP routers see very high traffic densities, the highest traffic
densities, because they are the focal point of DoS mitigation, flash
mobs and special event traffic spikes.

In the time frame where HTTP/2.0 will become standardized, HTTP
routers will routinely deal with 40Gbit/s traffic and people will
start to arcitect for 1Tbit/s traffic.

HTTP routers are usually only interested in a small part of the
HTTP request and barely in the response at all, usually only the
status code.

The demands for bandwidth efficiency has made makers of these devices
take many unwarranted shortcuts, for instance assuming that requests
always start on a packet boundary, "nulling out" HTTP headers by
changing the first character and so on.

Whatever HTTP/2.0 becomes, I strongly urge IETF and the WG to
formally recognize the role of HTTP routers, and to actively design
the protocol to make life easier for HTTP routers, so that they can
fulfill their job, while being standards compliant.

The need for HTTP routers does not disappear just because HTTPS is
employed, and serious thought should be turned to the question of
mixing HTTP and HTTPS traffic on the same TCP connection, while
allowing a HTTP router on the server side to correctly distribute
requests to different servers.

One simple way to gain a lot of benefit for little cost in this
area, would be to assign "flow-labels" which each are restricted
to one particular Host: header, allowing HTTP routers to only examine
the first request on each flow.

SPDY
----

SPDY has come a long way, and has served as a very worthwhile proof
of concept prototype, to document that there are gains to be had.

But as Frederick P. Brooks admonishes us:  Always throw the prototype
away and start over, because you will throw it away eventually, and
doing so early saves time and effort.

Overall, I find the design approach taken in SPDY deeply flawed.

For instance identifying the standardized HTTP headers, by a 4-byte
length and textual name, and then applying a deflate compressor to
save bandwidth is totally at odds with the job of HTTP routers which
need to quickly extract the Host: header in order to route the
traffic, preferably without committing extensive resources to each
request.

It is also not at all clear if the built-in dictionary is well
researched or just happens to work well for some subset of present
day websites, and at the very least some kind of versioning of this
dictionary should be incorporated.

It is still unclear for me if or how SPDY can be used on TCP port
80 or if it will need a WKS allocation of its own, which would open
a ton of issues with firewalling, filtering and proxying during
deployment.

(This is one of the things which makes it hard to avoid the feeling
that SPDY really wants to do away with all the "middle-men")

With my security-analyst hat on, I see a lot of DoS potential in
the SPDY protocol, many ways in which the client can make the server
expend resources, and foresee a lot of complexity in implementing
the server side to mitigate and deflect malicious traffic.

Server Push breaks the HTTP transaction model, and opens a pile of
cans of security and privacy issues, which whould not be sneaked
in during the design of a transport-encoding for HTTP/1+ traffic,
but rather be standardized as an independent and well analysed
extension to HTTP in general.

HTTP Speed+Mobility
-------------------

Is really just SPDY with WebSockets underneath.

I'm really not sure I see any benefit to that, execept that the
encoding chosen is marginally more efficient to implement in
hardware than SPDY.

I have not understood why it has "mobility" in the name, a word
which only makes an appearance in the ID as part of the name.

If the use of the word "mobility" only refers only to bandwidth
usage, I would call its use borderline-deceptive.

If it covers session stability across IP# changes for mobile
devices, I have missed it in my reading.

draft-tarreau-httpbis-network-friendly-00
-----------------------------------------

I have participated a little bit in this draft initially, but it
uses a number of concepts which I think are very problematic for
high performance (as in 1Tbit/s) implementations, for instance
variant-size length fields etc.

I do think the proposal is much better than the other two, taking
a much more fundamental view of the task, and if for no other reason,
because it takes an approach to bandwidth-saving based on enumeration
and repeat markers, rather than throwing everything after deflate
and hope for a miracle.

I think this protocol is the best basis to start from, but like
the other two, it has a long way to go, before it can truly 
earn the name HTTP/2.0.

Conclusion
----------

Overall, I don't see any of the three proposals offer anything that
will make the majority of web-sites go "Ohh we've been waiting for
that!"

Bigger sites will be entised by small bandwidth savings, but the
majority of the HTTP users will see scant or no net positive benefit
if one or more of these three proposals were to become HTTP/2.0

Considering how sketchy the HTTP/1.1 interop is described it is hard
to estimate how much trouble (as in: "Why doesn't this website work ?")
their deployment will cause, nor is it entirely clear to what extent
the experience with SPDY is representative of a wider deployment or
only of 'flying under the radar' with respect to people with an
interest in intercepting HTTP traffic.

Given the role of HTTP/1.1 in the net, I fear that the current rush
to push out a HTTP/2.0 by purely additive means is badly misguided,
and approaching a critical mass which will delay or prevent adoption
on its own.

At the end of the day, a HTTP request or a HTTP response is just
some metadata and an optional chunk of bytes as body, and if it
already takes 700 pages to standardize that, and HTTP/2.0 will add
another 100 pages to it, we're clearly doing something wrong.

I think it would be far better to start from scratch, look at what
HTTP/2.0 should actually do, and then design a simple, efficient
and future proof protocol to do just that, and leave behind all
the aggregations of badly thought out hacks of HTTP/1.1.

But to the extent that the WG produces a HTTP/2.0 protocol which
people will start to use, the Varnish project will be interested.

Poul-Henning Kamp
Author of Varnish

[1] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI
[2] http://varnish-cache.org/
[3] Yes, I'm that old.
[4] Which is really a transport level job, but it was left out of IPv6
    along with other useful features, to not delay adoption[5].
[5] No, I'm not kidding.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jul 2012 23:43:16 +0200

On 2012-07-13 01:48, Poul-Henning Kamp wrote:
> ...
> ...

Out of curiosity, how do you arrive at the "700 pages" estimate?

I see something like 15000 lines of text, and that includes all the 
change logs that we're going to remove before publication. So, do you 
have pages with 20 lines of text each???

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 13 Jul 2012 22:45:41 +0000

>Out of curiosity, how do you arrive at the "700 pages" estimate?

It comes from a friend who was tasked with identifying all applicable
specifications for their ecommerce site, except those where they
could rely on vendors ISO-9000 certification to ensure compliance.

HTTPS in particular pulls in a metric shitload of stuff.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2012 10:55:50 +1000

PHK -

Just a clarification or three.

Much of your commentary seems to assume that we're now deciding what HTTP/2.0 will be; in fact, we're choosing a starting point for further work. I have strong reason to be believe that many of the issues you raise will be discussed, and every reason to believe that what comes out will have substantial changes. Will the choice we make soon have influence over where we end up? Of course, but we have a lot to do before then.

You advocate (here and elsewhere) going back to the drawing board and doing things from scratch. In my experience (one that I believe is shared widely), that flat out doesn't work, and is a sure-fire recipe for either a) failing, or b) coming up with a committee-designed monstrosity (which is really just (a) drawn out). 

Finally, HTTP versioning is NOT like software versioning (where the driver is often marketing). As pointed out before, we're calling this HTTP/2.0 because we're talking about doing things that are incompatible with the wire format (not semantics) of HTTP/1.1. Again, see RFC2145.

Regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 06:43:12 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Much of your commentary seems to assume that we're now deciding what 
>HTTP/2.0 will be; in fact, we're choosing a starting point for further 
>work. 

No, my commentary is based on the experience that if you pick
a starting point, without first defining the problem(s) you are
trying to solve and the goal(s) you are trying to reach, then
that starting point is where you are going to end up. 

>You advocate (here and elsewhere) going back to the drawing board and 
>doing things from scratch.

No, I advocate starting out deciding what problems and goals HTTP/2.0
should address, what HTTP/1 did right and what it did wrong.

Only once we have a consensus about that, can we judge the
proposals fairly.

What the WG is engaged in right now is a popularity contest, it is
not engineering, and because of the inertia of popularity, it will
be impossible to change anything dramatically, no matter how wrong
it turns out to be.

That alone, in my mind, is reason to not chose SPDY as the starting
point:  The installed volume will deprive the WG of any real
influence.

Yes, I belive in rough consensus and all that, but I don't belive
you should always say yes to the first boy who invites you to the
dance.

>Finally, HTTP versioning is NOT like software versioning (where the 
>driver is often marketing).

I wish you good luck with keeping marketing and numerological
expectations away from the very head-line inviting "HTTP/2.0"
monicker.

lf I were you, I'd start to think about how I can explain HTTP/2.0
to journalists from the Daily Mail in a way that doesn't result in
"Boffins to close the web for upgrade" or "Web doesn't work says
head boffin" headlines.

I don't know if you have considered it, but it might be a much
better idea to standardize SPDY as "SPDY", and not roll out the
"HTTP/2.0" headline, until you have something real to show for it.

Given the total lack of interoperability between SPDY and HTTP/1,
that would also make a lot more technical sense.

---

From: Grahame Grieve <[email-masked]>
Date: Mon, 16 Jul 2012 16:55:46 +1000

+1

I'm just part of the long tail of http implementers. I don't
represent any large installed base, I've just written a few
http servers and clients because it's easy. One of the
reasons for the success of http/1.x is because you can
knock out a working server in a day.

All the proposals here seem very far from that. "Major
Web Companies lock down the web" seems more apt
as an inflammatory headline.. but perhaps the easy
problems have been solved easily, and only the hard
ones are left, and a two-speed web is the right way to go?

But it would be a shame to provide no cleaner simple http.

So +1 for defining the goals.

Grahame

--
-----
http://www.healthintersections.com.au / [email-masked]

-- 
-----
http://www.healthintersections.com.au / [email-masked]

---

From: James M Snell <[email-masked]>
Date: Mon, 16 Jul 2012 00:08:10 -0700

I would definitely have to +1 on this... My personal view of SPDY is that
it serves as an excellent place to at least start experimenting with
various options, testing ideas, getting our collective heads around what
types of things we could and should do before we define the actual solution
-- which may or may not look anything like SPDY in the end.

- James

On Sun, Jul 15, 2012 at 11:43 PM, Poul-Henning Kamp <[email-masked]>wrote:

> [snip]

---

From: "HAYASHI, Tatsuya" <[email-masked]>
Date: Mon, 16 Jul 2012 16:22:33 +0900

> So +1 for defining the goals.

+1.
I think so too.

--
HAYASHI, Tatsuya
Lepidum Co. Ltd.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2012 17:59:10 +1000

> that starting point is where you are going to end up. 

The goals were defined in our current charter:
  http://datatracker.ietf.org/wg/httpbis/charter/

In particular:

"""
To do this, the Working Group will solicit candidates for this work from 
the community, to be submitted as Internet-Drafts. Expected focus areas 
for candidates include: 

* Significantly improved perceived performance in common use cases 
(e.g., browsers, mobile) 
* More efficient use of network resources; in particular, reducing the 
need to use multiple TCP connections 
* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the 
presence of NATs 
* Maintaining HTTP's ease of deployment 
* Reflecting modern security requirements and practices 
"""

and

"""
The Working Group will then select a starting point for the new work 
based upon the following criteria: 

* Compatibility with HTTP/1.1 semantics; i.e., it must be possible to 
pass through a HTTP/1.1 message with reasonable fidelity 
* Broad implementer interest (e.g., from Web browsers, "back-end" 
or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.) 
"""

This was based upon discussion earlier this year. The time and place to argue our process was several months ago, not now.

> Only once we have a consensus about that, can we judge the

Again, we're already there. You're complaining about a decision that, effectively, the rest of the industry made months ago.

> be impossible to change anything dramatically, no matter how wrong

That's a lot of assumptions to make in one paragraph. 

> you should always say yes to the first boy who invites you to the

And that's why we're going through this process.

> "Boffins to close the web for upgrade" or "Web doesn't work says

Poul-Henning, you've waved your hands about regarding the press more than once now; it's getting old. Please tone down the rhetoric.

> "HTTP/2.0" headline, until you have something real to show for it.

Indeed, this was considered. However, it was felt that having SPDY become a de facto HTTP/2.0 outside the IETF process would be a worse outcome than having everyone at the table here, discussing it and other proposals, because it'll be a lot harder to change in the few years that would take -- to the point where it probably wouldn't be worth the effort.

Will HTTP/2.0 be perfect? I very much doubt it, and that's fine. What it will be is something that is better for HTTP/1.1 for most uses, for most people, in most situations -- or we won't do it. The process we're using now gives you -- a gateway / intermediary / "HTTP router" implementer -- a certain amount of influence over the outcome; influence that you wouldn't necessarily have over a separate effort. It doesn't give you the ability to stop the entire effort, nor to railroad everyone else down the path you've chosen (just as these aren't options open for any other single entity).

So, we need as many implementers and deployers constructively working together. So far, the folks who have made the proposals have taken pains to point out that they're willing to change, willing to negotiate, etc., as long as the changes are backed up by solid engineering. I'd ask you to work with us as well; the points you've made are good, and will be discussed, but the frustration you express so often isn't constructive, and indeed I don't think it's really necessary. 

> that would also make a lot more technical sense.

Please substantiate that claim, because it's apt to be taken out of context by the press whom you're so concerned about.

Kind regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Jul 2012 11:51:31 +0300

>  http://datatracker.ietf.org/wg/httpbis/charter/

Those are not goals. Quoting the first part of this:

   There is emerging implementation experience and interest in a protocol that 
   retains the semantics of HTTP, without the legacy of HTTP/1.x message framing 
   and syntax, which have been identified as hampering performance and encouraging 
   misuse of the underlying transport. 

   As such, there is an opportunity to create a new major 
   (non-wire-compatible) version of HTTP. 

   To do this, the Working Group will solicit candidates for this work from 
   the community, to be submitted as Internet-Drafts…

It doesn't say what these HTTP/2 candidates are supposed to do. All it says is:
 - they must retain HTTP semantics
 - they don't have to keep the message framing and syntax

Those are constraints, not goals. The charter doesn't even go so far as to specify "make web pages load faster" as a goal, or "better use of bandwidth", or even "prioritization of resources"

While we all seem to be working on the assumption that those are the goals, they're not stated anywhere. This is why we keep having discussions about whether server push is a MUST or a MUST NOT, and whether we need transport layer of application layer security, and whether those should be part of this proposal.

The popularity contest is not all bad. It gives us a much lower chance of failure, but PHK is right. Once we accept SPDY as the starting point of HTTP/2, changes are going to be minimal, because of all the running code and install base. While Chrome and Firefox update often, many servers hardly ever get updated. We'd need a very good reason for any departure from what SPDY/3 currently is, especially for any change that is not backwards compatible with the current SPDY.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Jul 2012 11:54:11 +0300

On Jul 16, 2012, at 10:08 AM, James M Snell wrote:

I would definitely have to +1 on this... My personal view of SPDY is that it serves as an excellent place to at least start experimenting with various options, testing ideas, getting our collective heads around what types of things we could and should do before we define the actual solution -- which may or may not look anything like SPDY in the end.

I also agree with this. However, by the time we experiment with various options, half the web browsers and a good portion of the web (Google+facebook+several others >10%) will be running SPDY, making it the de-facto next-generation HTTP

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Jul 2012 11:58:07 +0300

We may want to add to the requirements the definition of a "minimal implementation", such that supports only one concurrent stream, no server push, and default values for all tweakable parameters. Ideally we could test if such an implementation can be programmed in a day using a basic TCP library (for extra credit use just C and libC)

Yoav

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 09:16:51 +0000

In message <[email-masked]>, Mark Nottingham w
rites:

Mark,

The goals you point to are however goals for a WG, and I think they
are good goals for a WG, but they are not goals for a protocol.

Goals for a protocol would sound more like:

* "90% of all first requests fit in one packet on 1500 byte MTU"
* "request-reponse model." / "peer-to-peer model"
* "All protocol elements must be fixed size or length prefixed."
* "Must have multiplexing and pipelining"
* "Cryptographic protection is included/optional/mandatory"
* "Has (no) out-of-protection routing envelope"
* "Can (not) mix protected and unprotected requests on same connection"
* "No-extra-RT upgrade from HTTP/1 to HTTP/2"
* "Must demonstrate 10Gbit/sec load-balancer implementation on COTS PC"
* "Client must offer unique device or user identifier"
* "Not allow cookies or other server initiated tagging of client."
* "Replace User-agent with something of finite size and preferably usable."

and so on (examples only!)

Picking what you call "a starting point" -- no matter which of the three
you pick -- will put many of these decisions outside the reach of the WG.

Poul-Henning

PS: Your argument that it's better to have SPDY inside pissing out
than outside pissing in, is just capitulation by a different name.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 Jul 2012 19:28:42 +1000

We've agreed to how we're proceeding after extensive discussion previously. 

Changing that plan would require re-chartering, and while I hear a few people agreeing with you, I hear a lot more people who are committed to the path we're on. So, extra words from you at this point aren't going to do it; I need to hear broad consensus among people who implement and deploy HTTP to even consider this. 

Thanks,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 10:58:37 +0000

Mark,

When you issued a call for interest, you were inviting "extra words".

That you got.

It's quite clear from those extra words that SPDY is going to happen,
simply as a matter of sheer corporate power.

That doesn't mean it is a good idea, or even the best idea.

Enjoy,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Jul 2012 08:00:01 -0400

Lock in is certainly an issue. There are many features in HTTP/1.0
that remained the way they were because we were already a captive of
the deployed base.

But there are different types of lock in. Deployment at Facebook or
Google would not worry me very much because they are services. They
can move on to a new version of the software as quickly as they rolled
out SPDY.

What would worry me more on the server side is a sizable deployment
based on Apache or IIS. In particular takeup by the Web Hosting
companies.

On the client side, Chrome and firefox auto update, no real concern
there, Safari on an iphone 3 does not. So game over.

I would suggest though that the WG not commit to backwards
compatibility with SPDY. Instead I would argue for 'dont break without
a good purpose'.

-- 
Website: http://hallambaker.com/

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 16 Jul 2012 12:02:14 +0000

Hi all

After reading the reviews posted by/on behalf of twitter and facebook 
endorsing SPDY as-is (were they written by the same author?) I have to 
admit to getting the feeling we were going round in circles.

We had a long thread a few months back about whether encryption can be 
mandatory or not.  My understanding was that general consensus was 
achieved that it could not be mandatory, and that's why SPDY made it 
optional.  I suspect that deployment / interop issues with existing 
infrastructure play a large part in the desire to use NPN in TLS to 
establish support for SPDY or not, which provides a big incentive to 
push for TLS.  Frankly I don't believe it would actually improve 
security overall in the longer term.

Anyway, I would have a really big problem with any attempt to make 
encryption mandatory in the spec, and I think I (and others) already 
expressed the reasons before, so I won't repeat them here.  In the 
absense of any out-of-band negotiation of HTTP/2.0 support, and with 
the desire to not lose a R-T, we only really have 1 palatable option 
(other than using another port number which I still think may be 
preferable), and that's the Upgrade header.

Forgive me also for saying it looked like the FB and Twitter 
endorsements started from a position of having already decided SPDY was 
the way to go, and trying to justify that.  I can understand that, from 
their POV SPDY is really compelling, not the least because it is 
deployed and tested and has real benefits now.

And I don't have anything against SPDY, but I don't consider it to be 
HTTP. I see it as a transport / middle-layer which adds some nice 
features to transportation of HTTP/1.1 messages, but doesn't actually 
semantically change them (except for proposed server push, which AFAIK 
is still not really used?)

I'd like to see something that resolves some of the issues in HTTP 
itself, regardles of whether it goes over a multiplexed compressed 
encrypted connection or not.

>From a coding POV, I'd like to see 

* something that no longer requires parsing of strings or embedding of 
escapes to avoid conflicts with string-based token delimiters.  
* support from the ground-up for unicode
* less bloat

Also I'd like to see

* simplified caching controls that web developers can understand and 
use properly
* support for notifications
* support for scanning at an intermediary

overall maybe desire for simplification is a bit naive, but it still 
feels to me like there are a bunch of things that were patched on 
afterwards and had to be hacks.

Adrien

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Jul 2012 09:13:00 -0400

>From a very early point with spdy google has been open about its content
and open to input on it. At first that wasn't very thorough or organized
but that was more for lack of interest among any third parties - as more
people were willing to engage them the more effort they put into that
work. At this point spdy, as non-ietf work, has a busy public mailing
list full of technical discussion along with the results of actual
running code, working documents in public repositories, an engaged
editor (no longer even employed by google), and a vibrant forum for both
interop work and discussion on future development. In short, it works
better as an open process than 90% of IETF WGs do in practice.

What it lacks of course is governance. A structure like the IETF
guarantees continued open input in a way that a corporate structure
cannot. Google is conducting themselves admirably on this front, but a
company simply cannot make that guarantee alone.

Mozilla has been talking with Mike and team at Google for years before
we went ahead with this approach. Every time we had this discussion we
would push for an IETF process. Their response was consistent: as soon
as other organizations were ready to be part of that process they were
ready to dedicate resources to the IETF path. And here we are today -
with the protocol offered as the basis of a next step (and embraced by
many because it provably improves things), but open to the scrutiny of
all.

So rather than an exercise of "sheer corporate power" I think we're
seeing an excellent example of open consensus and running code.

-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Jul 2012 09:25:51 -0400

On Mon, 2012-07-16 at 11:51 +0300, Yoav Nir wrote:
>  While Chrome and Firefox update often, many servers hardly ever get
> updated. We'd need a very good reason for any departure from what
> SPDY/3 currently is, especially for any change that is not backwards
> compatible with the current SPDY.
> 

This is an important topic, and I think you have it (understandably)
wrong. Go ahead and break spdy/3 radically if that is right thing to
technically do!

SPDY is an experiment undergoing rapid change and standardization is
definitely part of that transition. If you cannot keep up with that
change you shouldn't be deploying it at this early stage of development.

I have spent a lot of time talking with many of the server side
implementations of spdy explaining that spdy/2 will be pushed off the
network from firefox probably at the time of deploying spdy/4...
followed by spdy/3 being pushed out by spdy/5, etc.. Nobody believes
that spdy is mature enough that we want it to be a defacto standard
forever.

At IETF-paris the chrome team and I had this discussion as well - I
can't speak for them or their algorithm but I can say in our discussion
they were even more adamant this general point than I am here. This
thing is totally breakable without leaving a trail of N versions to
support in its wake. That would be a disaster.

The realities of NPN deployment of SPDY make this easy during
standardization. Right now everyone running SPDY is running both HTTP/1
and some set of {spdy/2, spdy/3}.. If you had a (http/1 and spdy/2)
server that did not get any spdy updates by the time firefox dropped
spdy/2 support http/1 would silently be negotiated in its place. So
interop at least would continue.

-Patrick

---

From: Mike Belshe <[email-masked]>
Date: Mon, 16 Jul 2012 07:49:30 -0700

> * "Replace User-agent with something of finite size and preferably usable."
These are not goals.  These are requirements.   Goals generally have some
form of user benefit to them, like "reduce latency by 25%".  Your example
of "90% fit in one packet" is a requirement to achieve a goal.

> than outside pissing in, is just capitulation by a different name.

This is a pessimistic (and insulting) point of view.  You've got it in your
head that a the people that started on this work are idiots and unopen to
public debate.  We're not.  Do you think the other companies - from
Facebook to Twitter to Firefox would have ever built a protocol that they
thought was a Google proprietary special?  The answer is no - they want
this in all browsers and they are not dummies. They wouldn't invest into
SPDY if they thought it was Google only or had no chance of open
collaboration.  They only built it after meeting with me and others from
Google and getting  strong assurances that SPDY was headed for the
standardization process.

Anyway, I share Mark's views about the current process. It's going fine.
 From a practical standpoint, SPDY is the only proposal with any noteworthy
adoption.  But, that doesn't mean it can't change, and it doesn't mean
there aren't other things that need to be done.

I'm tired of hearing your anti-everything stance and direct attacks against
Google and SPDY.  We're here for a reason - to make something great and to
get agreement on it. What are you here for?

Starting with SPDY would not be "capitulation".  It would be starting with
the experience of at least 12 implementors from different vendors.  Which
other starting point offers you that?

Thanks,
Mike

---

From: Subbu Allamaraju <[email-masked]>
Date: Mon, 16 Jul 2012 08:11:32 -0700

> seeing an excellent example of open consensus and running code.
Well said.

Subbu

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 15:16:02 +0000

In message <[email-masked]>
, Mike Belshe writes:

>You've got it in your
>public debate.

No, I'm very impressed by what the SPDY has done, I've said so
repeatedly.

>Do you think the other companies - from Facebook to Twitter [...]

I think they are all very big companies with world wide distribution
of http-server facilities.

Most websites have only one geographical location.

This "we're everywhere" bias showed up in the initial release of
SPDY numbers, which looked wonderful, thanks the the fact that Google
has low RTT to anybody in the world, and thus could "afford" the
TLS-RTT penalty, a luxury not many websites have.

But my major problem with SPDY is simply that it is additive,
it just adds another 50 pages of sediment to the pile of RFCs
necessary to implement HTTP.

SPDY does nothing to address problems like User-Agent, Cookie,
ASCII representation of timestamps, it just throws it all
into deflate and hopes for the best.

Take the discussion going on about "non-GMT" timestamps right
now as example:  Resolving that is probably going to add another
20 lines of text to clarify.

If HTTP/2.0 defines all timestamps as a POSIX::time_t binary
timestamp, you can rip out the entire section 8 out of part2, 
eliminate tons of weird error-cases and their handling, and
everybody in the HTTP-chain will save cpu cycles.

That is the sort of improvement I expect from HTTP/1 to HTTP/2
and SPDY does not deliver it.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 16 Jul 2012 09:40:57 -0700

> TLS-RTT penalty, a luxury not many websites have.

That is backwards for much content -- something which multiplexes is more
beneficial to things experiencing higher RTT.

Basically the expectation was that less optimized sites (either code or
location) would benefit more from SPDY than sites which were already well
connected and whose pages are well optimized

> into deflate and hopes for the best.

It is just a start. If we'd attempted all of that in the beginning I think
we'd have a failed effort by now.

I'm happy to get changed whatever we can so long as it improved things and
is deployable. This has always been the mantra, but at this venue and at
this period in time the scope if then changes which can be considered has
broadened.

 On Jul 16, 2012 8:17 AM, "Poul-Henning Kamp" <[email-masked]> wrote:

> In message <
> [email-masked]>
> , Mike Belshe writes:
>
> >You've got it in your

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 19:30:35 +0000

In message <[email-masked]>

>we'd have a failed effort by now.

Which is why I applaud SPDY as a damn good prototype, which taught us
a lot, for instance that shoving everything into deflate showed that
it matters how big requests are, and that there are significant gains
to be had.

What we should do now is throw the prototype away, and design a
serialization of HTTP which is as if not more efficient than deflate,
and which is less hostile to HTTP routers less prone to DoS
exploitation, and takes less memory footprint (code&data) to implement.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 16 Jul 2012 13:05:05 -0700

On Mon, Jul 16, 2012 at 12:30 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Roberto Peon writes:
>

We're all here to try to do that, as far as I know.   :)
-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 20:14:09 +0000

In message <[email-masked]>

>We're all here to try to do that, as far as I know.   :)

Well, that's not the vibe that transmits all the way over here, from
here it sounds like: "adopt SPDY as the starting point, rearrange
the deck-chairs a bit then call it HTTP/2.0"

But the proof is in the pudding:  The best way to shut me up is to do
a damn good job.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 16 Jul 2012 22:46:50 +0200

> But the proof is in the pudding:  The best way to shut me up is to do

Poul-Henning, we're *really* here to improve this, I mean *really*.

When we started with Amos, I said "let's not waste our time redesigning
flow control, SPDY already has it, let's address what we don't agree with
first". We worked hard to improve a few points. The result is that we don't
have a complete proposal but something to experiment with, a PoC (and a
lib almost ready in Amos' bag).

I don't care a dime *whose* proposal is used as a basis, leave this to the
press who only sees a fight between google and microsoft to own HTTP/2. Facts
are that SPDY has the most experience. Others brought different ideas. I like
Gabriel's idea of trying to build a common layer for WS and HTTP eventhough I
don't like much the first proposal. I like the experiments we have done
consecutive to our draft eventhough I don't like at all how it's proposed
right now. I liked a lot Roy's presentation of Waka and am terribly sad it's
still not in a draft.

This is about making progress through experimentation. I mean, even if in
the end we adopt 100% of SPDY after all other attempts have failed, then we
will know it was the best tradeoff. Right now I'm far from being convinced
of that and that's why I'm motivated in experimenting with other tracks.
And I'd say even the SPDY guys are open to this.

So we're here to make engineering work, to vigorously defend our ideas,
fears and expectations, but only on technical grounds.

It's perfectly expected that some early adopters report a big success.
We should just consider this with a grain of salt when they're dealing
with monster datacenters, but they represent a valid use case. Even some
early adopters had mixed opinions, that's expected too. Some developers
have fears that are expected. All what happens here is normal and it's
not because 3-4 very satisfied implementers support one protocol that
it suddenly the protocol of everyone. However it could become de facto
if the WG cannot make progress to standardize something !

We're not here to win anything, we're here to improve HTTP so that we
don't have to implement something which causes more issues than it solves,
because in the end, we will *all* have to implement HTTP/2.0, so we must
like it first. *This* is what I'm doing here and what I hope most of us
are doing here.

It's also why I'm afraid of the timing BTW, some of us difficultly have
more time to spend on this and it's a shame because some experiments are
needed.

I also remember that in private with a few of us you proposed a draft
that you never published. There were very valid concerns here. Why do
you not share it so that good ideas can be picked from it ? It would
help a lot more than attacking the proposal that already gets support
for already being deployed at some places.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 16 Jul 2012 21:18:51 +0000

In message <[email-masked]>, Willy Tarreau writes:

>you not share it so that good ideas can be picked from it ?

The main reason that it never made it to ID, is that there quite
clearly is no room in the timeplan for the kind of fundamental
contemplation I wanted to inspire, so it seemed a waste of both
my own and everybody elses time.

There's nothing secret about it, and I don't think there is anything
in it which havn't already been mentioned in emails too:

   http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-architecture-01.txt

Please disregard any strangeness in the boilerplate, I may not
thrown all the right spells at xml2rfc, and also note that I have
subsequently changed my mind on certain subjects, most notably
Cookies which should simply be exterminated from HTTP/2.0, and
replaced with a stable session/identity concept which does not make
it possible or necessary for servers to store data on the clients.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 Jul 2012 00:04:05 +0200

>    http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-architecture-01.txt

Thank you.

> it possible or necessary for servers to store data on the clients.

It's normal to change one's mind. We're designing. I changed mine
several times on some subject and am not ashamed of this. You even
made me change my mind about some points on the encoding. That's fine.

That's a point where I agree with Mike when he constantly repeats
"show me the data". Of course producing data take a huge amount of
time but in the end we know why we want the things one way or another.

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Mon, 16 Jul 2012 20:30:24 -0700

> http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-architecture-01.txt

This is not a spec - you can't implement anything from this.

It's just a long winded, I-D resembling rant against SPDY.

As usual from this author, it does not cite data, evidence or
implementation experience.

Sigh.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 05:02:59 +0000

In message <[email-masked]>

>This is not a spec - you can't implement anything from this.

Which part of
	"Before rushing into standardization of HTTP/2.0 based on
	past experience and grievances with HTTP/1.1, we should
	examine what the architecture underlying the next 10-20
	years of web-browsing must do for us."

Didn't you understand ?

---

From: Brian Pane <[email-masked]>
Date: Mon, 16 Jul 2012 23:25:30 -0700

>    http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-architecture-01.txt

Thanks for sharing this.  Here are some thoughts on it, from my
perspective as a person who develops load balancers for a living:

My key takeaway from your draft is that you're advocating for HTTP/2.0
to have a wire format that can be parsed with efficiency much closer
to TCP (fixed-sized fields, binary values, both the code and the data
can fit in a small number of cache lines) than to HTTP/1.1
(variable-length fields with nontrivial delimiter semantics, ASCII
values, not-at-all-compact data, parsing code ends up being large and
full of conditional branches).

On one hand, that concept has a definite appeal.  In ever web server,
proxy, and load balancer on which I've ever worked, HTTP parsing has
been embarrassingly expensive.  On the other hand, that embarrassingly
expensive parsing cost still tends to be only a single-digit
percentage of total CPU usage in real-world proxies.  So is it
worthwhile to reduce that parsing cost?  Well, it depends on the
tradeoffs we have to make in the process.

Section 9.1 defines a very small set of message components that are
available to the "HTTP router" in an efficient representation.  An
HTTP router will have fast access to the requested path, the requested
hostname, and a session ID, plus everything in the L3 and L4 headers.
That's a proper subset of the things a load balancer can use to choose
a destination.  It's an adequate subset for some sites, but not for
others.  In my own experience working at websites ranging from tiny to
very large, the ones with very high traffic also had complicated load
balancing rules - e.g., routing traffic based on cookies that
persisted across sessions, routing based on query parameters, and even
routing based on custom headers inserted by a previous hop in a
multi-tier hierarchy.  In the terminology of section 9.2, the larger
sites needed "regular HTTP proxies."  In my terminology, they needed
load balancers.  In marketing terminology, they needed Application
Delivery Controllers.

But that's just my experience.  In general, the concept of
representing a few commonly-referenced message components in a
lightweight, cheap-to-parse format might be useful to people, and it's
something that could be added into a design like SPDY or HTTP
Speed+Mobility.

I think it would be illuminating to hear from some people who have
sites with 1) very high traffic (big enough to care about high-speed
request parsing and routing), 2) complicated enough load balancing
needs that they're doing L7 rather than L4 load balancing, and 3)
simple enough load balancing needs that the fields outlined in section
9.1 would suffice.  Those folks may have some good empirical data to
help show whether there's a general need for an "HTTP-router-friendly"
optimization in HTTP/2.0.

-Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 07:08:08 +0000

In message <[email-masked]>
, Brian Pane writes:

>to TCP [...]

Yes, at least for the routing envelope.

The metadata and content should probably be squeezed as hard as we
reasonably can.

>available to the "HTTP router" in an efficient representation. 

This is one of the places where I've changed my mind a fair bit
since I wrote this, in particular with respect to URI, and cookies,
but the general idea still holds.

>e.g., routing traffic based on cookies that
>multi-tier hierarchy.

(Cookies are gone in my vision of HTTP/2.0 by now, instead you'll
have a client created and supplied session identifier.)

Yes, there are times and places where you need more detailed
routing, and if so, you'll have to pay the cost of taking it
all apart.

But a very large fraction of all HTTP-routing is by "Host:" header
only, and if you add URI and session-id to that, I wouldn't be
surprised if you have covered 90% of all HTTP routing based on the
request.  (Obviously a lot of routing happens on the basis of server
availability, but that is unaffected by the protocol.)

There is a significant gain to be had for all routing, also the
more complex kind you mention, if the multiplex-ID/stream-ID can
double as a flow-label for routing, so the router only have to
examine the first request on each stream, and let all subsequent
requests follow the same decision.

One further optimization from there, could be to only send the
envelope when you open a new stream/mux-channel, but I'm not
sure if that would be a net pessimization or optimization.

>request parsing and routing), 

I'd much rather ask a VHDL/Verilog wizard: "How would you
route HTTP requests at 1Tbit/s in an FPGA ?"

The routable envelope is meant to be a hedge for the future: We
might be able to route 10 or even 40Gbit/s on todays silicon, but
if we want to do it to 1Tbit/s on tomorrows silicon, I am sure need
to make the task easier, because the silicon isn't getting faster,
it's just getting wider.

But as I hope is clear:  This was intended as food for long-range
thought, not as a concrete proposal.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 00:09:52 -0700

On Mon, Jul 16, 2012 at 10:02 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Mike Belshe writes:
>
> >>

SPDY's concepts are not new or revolutionary.  None of the concepts haven't
been seen before in other protocols (multiplexing, prioritization,
compression, etc).  We just assembled them in a coherent way that a lot of
people have advocated for a very long time and that have now been proven to
work well for HTTP.

There is no rushing going on here - these are tried and true techniques
that are ready for the next generation of HTTP now, and they've already
been in development for 3 years.  This is not a prototype.  This is the
real deal.  It will change, of course, but its a very solid starting point.

So its not that I didn't understand anything you said, it's just that
you're still trying to catch up. :-)

Mike

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Jul 2012 10:21:49 +0300

On Jul 17, 2012, at 9:25 AM, Brian Pane wrote:

> percentage of total CPU usage in real-world proxies.  

OK. The suspense is killing me. Where do the rest of the CPU cycles go. Reading PHK's draft, the router reads a request, parses it, and forwards it (almost as is) to another TCP stream. I can see how parsing takes some CPU cycles. Where does the rest go?

Thanks

Yoav

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 00:50:36 -0700

> In message <
[email-masked]>
> >request parsing and routing),

I have experience with such. Mapping URL space and determining routing is a
huge pain in the posterior, but the problem is more social than
technological. :/

Parsing the same crud over and over again (and, more specifically doing the
memory management associated with such) is the most bothersome component at
this layer. Being informed only when things change is probably a better
idea and one which will be fun and interesting to pursue.

> route HTTP requests at 1Tbit/s in an FPGA ?"

The base problem isn't the technology-- I bet that we could get something
in software going at line rate, limited mainly by bus speeds if the
configuration space for the mapping (call it route discovery) were simple
enough.

The holdup is that users have bookmarks, external links, etc. and so sites
are reasonably reluctant to change their (unfortunately complex and
potentially order dependent rule) mappings when doing so might lose them
traffic.
Ignoring bookmarks and other links, it is still problematic to get a site
to change the mappings because they'll have to support both the HTTP/2
stuff and the http/1 stuff. They're not likely to do it. It would take a
massive effort to make such a thing happen.

It gets worse when one considers pieces of hardware which are not
upgradable and have url-space hardwired into their firmware. One must wait
until most such devices and appliances have reached their end-of-life, and
pray that none have replaced it using similar designs with different fixed
url-space.

So, the problem is that we're stuck with this for the foreseeable future, I
believe.

We could define a new approach that was useful separately by encoding some
other, non-human readable information into the URL or equivalent, but... we
could already do that but don't.

If we wish to improve this part of the problem, the question is why we
don't bother to use mechanisms that already enabled with today's
tech/feature set.
Any ideas as to how to reprogram site designers/authors? :)

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 09:04:57 +0000

In message <[email-masked]>

>potentially order dependent rule) mappings when doing so might lose them

Fortunately 1Tbit/s isn't going to happen over night either.

>upgradable and have url-space hardwired into their firmware. 

I don't think there is any realistic prospect of retiring HTTP/1.x
entirely in the next 10 years.   In 15 years maybe.

But if we do HTTP/2 right, the amount of traffic left on HTTP/1.x
would be cut in half about three years after HTTP/2.0 ratification.

If we do a good job, in particular on HTTP/1->HTTP/2 connection
upgrades, it will happen even sooner than that.

>Any ideas as to how to reprogram site designers/authors? :)

Is it important or even necessary to do so ?

If they work for a site where performance matters, there will
be a local feedback loop to steer them in the right direction.

If they work a place where performance doesn't matter, they would
be wasting time by optimizing for performance in the first place.

But delivering a simpler to understand protocol would certainly
help, for instance many webdesigners have only very sketchy ideas
about how cookies and authentication actually work.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 17 Jul 2012 09:49:47 +0000

In message <CABaLYCu=[email-masked]>
, Mike Belshe writes:

Mike,

Could you please stop taking my critique of SPDY as a personal affront ?

I have nothing against you (or anybody else here) as persons.

We cleary disagree what constitutes a "prototype" vs. "the real deal"
but that has nothing to do with you or me as persons.