Subject: QUIC should be designed for HTTP-Next, not HTTP/2

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Feb 2017 12:20:33 -0500

Like many folk, I had assumed that QUIC should be designed as the next
generation TCP to support HTTP/2 which is in turn designed to support Web
browsing.

I just realized, that is probably a mistake.

HTTP for Web browsing is not a protocol I have given much thought to since
I left the Web consortium in '96. The chief design goal of HTTP/1.1 was to
make the Web work well on dialup. And caching proxies were one of our main
tools.

HTTP/2 does two things, it optimizes the transfer of header information and
it requires use of transport security which has the pleasing (to me) effect
of disabling intermediaries.

QUIC does many things, including fusing TLS and TCP framing which is a much
needed improvement. And it will certainly be a better transport choice for
HTTP/2.

But what would HTTP for browsing look like if we completely redesigned it
for QUIC?

BTW, I am aware that HTTP is used for other things, in fact most of my work
is on Web Services. But HTTP/2 is even less relevant there as the only HTTP
header we usually use are Host and Cache-Control: Never.

The best header optimization is not to send them at all. And we can
certainly get rid of all the junk that was there for the intermediaries
that can't read any of it in any case because it is encrypted.

Modern Web pages are by necessity composite objects because most of the
expensive to transmit resources appear on multiple pages. The HTTP model is
that we request a resource, we get a response, we request another one.

First off, content negotiation is not going to change across requests. A
browser is not going to learn to interpret a new image format between one
request and another for the same page. Or not often enough to bother.

So I had assumed we would be using some form of scheme where we push the
content negotiation headers at the start of a connection and amortize them
across multiple requests.

But there is an interesting alternative. A modern Web server can (and
usually does) caching internally. So let us assume that the Web server
caches the URI stem (the host but not any query part) and the resource it
maps to. Out protocol for browsing could then become

1) Request the parent content for the page (i.e. the outer HTML)
2) Send a single request for all the parts that are not cached locally by
SHA-256 (URI)
3) Send a single request re-requesting any hashes that were not recognized
by the server

Each entry in the batched request would consist of:

Content identifier [URI or SHA-256(URI)]
Cache information [Digest of possibly stale content or other depending on
model declared in the cached data]

With this model we can reduce requests to 40 bytes and pack ~20 requests
into a single packet without even using jumbo frames(!)

Of course it would be a mistake to build both together. Error 33, do not
build research on research. But the advantages of this approach are going
to make it all but inevitable when QUIC matures. The point of raising this
now is that what I am seeing in descriptions is QUIC = TCP + TLS + HTTP/2
and I don't think the last bit is going to be right at all.

In the Web Services space, all I am interested in really is the ability to
define virtual port numbers for my services and some really basic framing.
These can be provided by a really simple layer on QUIC that has nothing to
do with HTTP.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Feb 2017 17:49:54 +0000

I would characterize HTTP/2 differently – as the RFC says, it’s an optimized mapping of (unchanged) HTTP semantics to TCP.  And HTTP/QUIC is not HTTP/2 – it is a mapping of those same HTTP semantics to QUIC.  There will be similarities to HTTP/2, because QUIC provides many of the faculties HTTP/2 built for itself in the framing layer atop TCP.  There will also be differences, because QUIC is not TCP + framing layer.

What you’re talking about is a major change to HTTP semantics themselves, regardless of the transport mapping that’s used to carry the new semantics.  I’m certainly not averse to that, and the httpbis WG has discussed in the past that we might consider a breaking-change version that evolves the HTTP semantic layer in the future.  However, I think you’re on the right page with “don’t build research on research.”  This WG is chartered to map existing HTTP semantics to the new transport. Once the transport itself is stable, it may well be the best substrate for the httpbis WG to use when developing the successor to HTTP, but that’s an item for the future.  (I also think that the new semantics could likely be carried over TCP, possibly with a framing layer, if there’s appetite to build it.)

From: QUIC [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, February 23, 2017 9:21 AM
To: IETF QUIC WG <[email-masked]>
Subject: QUIC should be designed for HTTP-Next, not HTTP/2

Like many folk, I had assumed that QUIC should be designed as the next generation TCP to support HTTP/2 which is in turn designed to support Web browsing.

HTTP for Web browsing is not a protocol I have given much thought to since I left the Web consortium in '96. The chief design goal of HTTP/1.1 was to make the Web work well on dialup. And caching proxies were one of our main tools.

HTTP/2 does two things, it optimizes the transfer of header information and it requires use of transport security which has the pleasing (to me) effect of disabling intermediaries.

QUIC does many things, including fusing TLS and TCP framing which is a much needed improvement. And it will certainly be a better transport choice for HTTP/2.

But what would HTTP for browsing look like if we completely redesigned it for QUIC?

BTW, I am aware that HTTP is used for other things, in fact most of my work is on Web Services. But HTTP/2 is even less relevant there as the only HTTP header we usually use are Host and Cache-Control: Never.

The best header optimization is not to send them at all. And we can certainly get rid of all the junk that was there for the intermediaries that can't read any of it in any case because it is encrypted.

Modern Web pages are by necessity composite objects because most of the expensive to transmit resources appear on multiple pages. The HTTP model is that we request a resource, we get a response, we request another one.

First off, content negotiation is not going to change across requests. A browser is not going to learn to interpret a new image format between one request and another for the same page. Or not often enough to bother.

So I had assumed we would be using some form of scheme where we push the content negotiation headers at the start of a connection and amortize them across multiple requests.

But there is an interesting alternative. A modern Web server can (and usually does) caching internally. So let us assume that the Web server caches the URI stem (the host but not any query part) and the resource it maps to. Out protocol for browsing could then become

1) Request the parent content for the page (i.e. the outer HTML)
2) Send a single request for all the parts that are not cached locally by SHA-256 (URI)
3) Send a single request re-requesting any hashes that were not recognized by the server

Content identifier [URI or SHA-256(URI)]
Cache information [Digest of possibly stale content or other depending on model declared in the cached data]

With this model we can reduce requests to 40 bytes and pack ~20 requests into a single packet without even using jumbo frames(!)

Of course it would be a mistake to build both together. Error 33, do not build research on research. But the advantages of this approach are going to make it all but inevitable when QUIC matures. The point of raising this now is that what I am seeing in descriptions is QUIC = TCP + TLS + HTTP/2 and I don't think the last bit is going to be right at all.

In the Web Services space, all I am interested in really is the ability to define virtual port numbers for my services and some really basic framing. These can be provided by a really simple layer on QUIC that has nothing to do with HTTP.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Feb 2017 19:41:24 +0100

To state the obvious: then it would need to be defined in the HTTP WG...

On 2017-02-23 18:20, Phillip Hallam-Baker wrote:
> ...
> browser is not going to learn to interpret a new image format between
> one request and another for the same page. Or not often enough to bother.
>
> content negotiation headers at the start of a connection and amortize
> them across multiple requests.
> ...

That's what HPACK already does in HTTP/2, no?

> ...

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Feb 2017 17:03:17 -0500

> To state the obvious: then it would need to be defined in the HTTP WG...

​Ummm no. That is the very last place I would want to discuss it.​

​This would not be HTTP/3, it would be a complete discontinuity.

It certainly isn't something to start building in QUIC either. But the way
I look at it, QUIC is similar to a subway system for a city. When you are
building a subway you don't just build it for the city as it is today, you
build it for what you expect it to grow into.

The easy part of QUIC is going to be building the protocol itself. The part
that always ends up being hard is how to move from the legacy base to the
new system efficiently in a way that does not foreclose future growth.​

> That's what HPACK already does in HTTP/2, no?

​Like I said, that is the scheme I th​ought we would be the end point but I
now see it as merely a waypoint to something else.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Feb 2017 18:25:16 -0800

On Thu, Feb 23, 2017 at 2:03 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
> Ummm no. That is the very last place I would want to discuss it.
>
> This would not be HTTP/3, it would be a complete discontinuity.
>
> It certainly isn't something to start building in QUIC either. But the way I
> look at it, QUIC is similar to a subway system for a city. When you are
> new system efficiently in a way that does not foreclose future growth.

Dear Philip,
QUIC provides a negotiation mechanism for the transported protocol. It
provides multiplexed schemes. What specifically do you think is
forclosing the possibility of other transports?
Sincerely,
Watson

> Like I said, that is the scheme I thought we would be the end point but I

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Feb 2017 21:40:18 -0500

> forclosing the possibility of other transports?
​The fact that I expect certain parties to demand it be achieved in zero
round trips (or less). ​