Subject: Ascii-based SPDY "compression" idea

From: Peter Lepeska <[email-masked]>
Date: Sun, 1 Apr 2012 12:50:20 -0400

>From the SPDY whitepaper <http://dev.chromium.org/spdy/spdy-whitepaper>,
the primary performance benefit of header compression is in the upload
direction. The benefit can be as much as a 1 second impact for slow DSL
(375 Kbps) links based on these tests. This is primarily due to long
repeating strings in URLs, User Agents, and Cookies. Ideally we could find
a way to reduce the bytes associated with these headers without obscuring
them.

Since a SPDY session is associated with a single TCP connection, we can
assume all GETs on that connection are being routed to the same web server.
This allows us to consider other "compression" schemes for SPDY that will
maintain transparency on the wire, or at least make it easier for tools to
be built to interpret the headers. For instance, in a given TCP connection
/ SPDY session, HTTP headers in GETs and responses can be dropped if they
have the same value as previous. If different from previous, only
differences can be sent. This would immediately drop User Agent headers
from all but the first GET. Additionally requests would contain only
cookies whose values are changing, similar to the way that Set-Cookie works
in HTTP responses today. Even URLs could use relative paths from the
previous object.

This would provide some of the benefit of header compression without any of
the opaqueness downside.

Peter

On Sun, Apr 1, 2012 at 12:39 AM, Willy Tarreau <[email-masked]> wrote:
>
> On Fri, Mar 30, 2012 at 03:22:12PM +0200, Mike Belshe wrote:
> > What is "transparency on the wire"?  You mean an ascii protocol that you
> > can read?  I don't think this is a very interesting goal, as most people
> > don't look at the wire.
>
> I agree with you here Mike, despite being used to look at network captures
> all the day and testing proxies with "printf|netcat" at both ends. But we
> must admit that if developers need tools, they will develop their tools.
> Having an HTTP option for netcat would work well, or even having an
1.1-to-2.0
> and 2.0-to-1.1 message converter on stdin/stdout would do the trick. So I
> prefer to lose the ability to easily debug and have something efficient
than
> the opposite. And it costs me a lot to say this :-)
>
> Willy
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 1 Apr 2012 20:14:35 +0200

Hi Peter,

> a way to reduce the bytes associated with these headers without obscuring

The goal is now to optimize every agent in the chain, not to make it easy
to read them from a human eye. Something like 1 requests over 1 billion is
read by a human, yet networks are full of them and parsers have a lot of
difficulties trying to get them right because they're made for humans.
Don't get me wrong, I *love* to read captures and to quickly spot what's
right or wrong, but people who do this like me are also able to develop
some additional tools to continue doing this.

> in HTTP responses today. Even URLs could use relative paths from the

You should then take a look at what is proposed in our draft here, as it's more
or less what you're describing, with binary-encoded header field names in order
to save more space (stop sending "if-modified-since" for instance) :

  http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00

Best regards,
Willy

---

From: Tim Bray <[email-masked]>
Date: Sun, 1 Apr 2012 11:17:36 -0700

This works IF all the requests get sent to the same web server.  This
is quite possibly not true in particular with GET requests to a large
web-facing property with a sharded cache.  At a deeper level, it
requires more server state, which can be quite expensive in some
cases.

But still, quite a clever idea.

 -T

On Sun, Apr 1, 2012 at 9:50 AM, Peter Lepeska <[email-masked]> wrote:
> >From the SPDY whitepaper, the primary performance benefit of header
> compression is in the upload direction. The benefit can be as much as a 1
> second impact for slow DSL (375 Kbps) links based on these tests. This is
> primarily due to long repeating strings in URLs, User Agents, and Cookies.
> Ideally we could find a way to reduce the bytes associated with these
> headers without obscuring them.
>
> be built to interpret the headers. For instance, in a given TCP connection /
> SPDY session, HTTP headers in GETs and responses can be dropped if they have
> the same value as previous. If different from previous, only differences can
> be sent. This would immediately drop User Agent headers from all but the
> first GET. Additionally requests would contain only cookies whose values are
> changing, similar to the way that Set-Cookie works in HTTP responses today.
> Even URLs could use relative paths from the previous object.
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 1 Apr 2012 20:30:08 +0200

>   http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00

BTW I'm realizing that the slides are probably easier to read than the draft :

   http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-0.pdf

Willy

---

From: Peter Lepeska <[email-masked]>
Date: Sun, 1 Apr 2012 15:20:15 -0400

"it requires more server state, which can be quite expensive in some cases."

Right, it trades off byte savings and the need to deal with more per
connection state on the server -- just like SPDY's compression.

About sending to the same server, I agree this could only be applied to
data across persistent HTTP connections or SPDY connections, both of
which will be terminated and parsed by a single server.

Peter

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 1 Apr 2012 22:50:51 +0200

> some additional tools to continue doing this.

I agree with Willy. Peter, while it's indeed useful to discuss different
compression schemes, I'd urge you to stop optimizing for humans, since they
will write tools. Note that SPDY is pretty simple to write a tool for. I
think there are on the order of 20+ different implementations of it now,
which demonstrates that it is not hard.

While we're talking about tools, note that Adam Langley wrote code in NSS
(used by Chromium) to dump the secrets for TLS connections to stdout, which
can be imported into Wireshark to decode TLS streams.

>  http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00

Thanks for mentioning this Willy. Can you implement this and provide data
on how it performs? I think it will better inform the debate.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 1 Apr 2012 23:08:45 +0200

Hi William,

> on how it performs? I think it will better inform the debate.

Will try to. It will probably only be based on captures of a proxy
traffic right now because writing proxies is a long painful task !

Willy

---

From: Roberto Peon <[email-masked]>
Date: Sun, 1 Apr 2012 23:31:50 +0200

++

Willy has it right here.

The goal is to optimize for the user, not to make it easy to debug one
request at the cost of user experience or network price when we as
implementers are perfectly able to create tools that turn the binary into
formatted text and graphics.

-=R

---

From: Peter Lepeska <[email-masked]>
Date: Sun, 1 Apr 2012 17:58:00 -0400

Hi Willy,

Thanks for sending this. A lot of good stuff in here -- removal of
redundant headers, binary names and lengths is great.

I'll post comments after a closer reading.

Thanks,

Peter

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 00:11:23 +0000

In message <[email-masked]>

>assume all GETs on that connection are being routed to the same web server.

I think that is an unwarranted assumption.

Many sites today will deliver static content like images from one
set of servers and dynamic content from another (typically larger)
set of servers, and some kind of "http-router" will split the
requests on the TCP connection up between them.

-- 
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: Willy Tarreau <[email-masked]>
Date: Mon, 2 Apr 2012 07:31:16 +0200

> I'll post comments after a closer reading.

Thank you. We're currently discussing the frame format which we still
don't like much (it was more to propose something possible than to
propose something optimal), so don't waste your time trying to analyze
it :-)

You might also be interested by Roy's presentation of Waka too, which
came to the same conclusions us but many years before :-) He also went
slightly further by separating representation headers from transport
headers :

   http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf

I hope he finds the time to write a draft, because it looks really
promising.

Willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 2 Apr 2012 12:13:10 +0200

On Mon, Apr 2, 2012 at 2:11 AM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Peter Lepeska writes:
>

Just to be clear, is this "http-router" a reverse proxy that terminates the
TCP connection and forwards HTTP requests onward to backend application
servers? Because if so, then I think the core of Peter's point still
stands. The "http-router" can handle all the header
compression/decompression for SPDY.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 10:30:04 +0000

In message <CAA4WUYhpCJMNVBdPG8-zg24aEvYdZk171PknEEy5oyWKgi=[email-masked]>
, =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:
>--00248c711a11f88a2104bcaf6f27

>Because if so, then I think the core of Peter's point still

For small loads, yes, it probably can.

For 1Tb/s:  No way in hell it can.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 2 Apr 2012 14:10:40 +0200

It's unclear to me the point that you're making. Above, Peter said "Since a
SPDY session is associated with a single TCP connection, we can assume all
GETs on that connection are being routed to the same web server." to which
you said "I think that is an unwarranted assumption."

So, just to clarify, we're on agreement that all GETs are being routed to
the same HTTP router, right? I understand that intermediary authors have
concerns about the use of compression at all and also about the type of
compression, but I think that's orthogonal to Peter's above point.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 13:17:51 +0000

In message <CAA4WUYg79y39s3M=[email-masked]>
, =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= writes:

>the same HTTP router, right?

Yes, they go to the same HTTP router, but very likely different
HTTP servers.

I strongly belive that we need to recognize HTTP routers as a class
in HTTP/2.0, a class semi-distinct from the more general proxy,
because they handle the biggest bandwidths and look at the smallest
parts of the HTTP headers.

Proxies with more functionality, caching or filtering for instance
by definition needs to look at more of the metadata becuase they
are, at some level, involved in the semantics.

But the basic HTTP-router just needs to figure out which webserver
this goes to and the primary criteria seems to be:
	Host:
	URI pattern match
	session-cookie
in that order.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 01:36:12 +1200

On 3/04/2012 12:10 a.m., William Chan (陈智昌) wrote:
> It's unclear to me the point that you're making. Above, Peter said 
> "Since a SPDY session is associated with a single TCP connection, we 
> can assume all GETs on that connection are being routed to the same 
> web server." to which you said "I think that is an unwarranted 
> assumption."
>
> So, just to clarify, we're on agreement that all GETs are being routed 
> to the same HTTP router, right? I understand that intermediary authors 
> have concerns about the use of compression at all and also about the 
> type of compression, but I think that's orthogonal to Peter's above point.

The assumption that its a web server which is receiving the requests is 
not a valid one. Transparent multiplex/aggregation/load balancer proxy 
is just three types of intermediary which violate that assumption, and 
we have not got anywhere near the more complex things like TCP 
splitters. SPDY using TLS avoided many of them so far, whatever gets 
approved they will likely all be updated to hook into the HTTP/2 
protocol like they do HTTP/1.

Assuming that the host can be bound to the TCP layer details prohibits 
all types of multiplexing, virtual hosting and intermediary pipelining 
from being done in the middle. The net result of that is to cap ISP at 
around concurrent 64K pipelines per box, with each restricted to only 
one origin servers traffic. That is an unreasonably low limit.
Unless the middleware add layering hacks to transit the details over 
multiplexed connections. Which can only lead to interoperability pain.

AYJ

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 2 Apr 2012 07:16:53 -0700

I'm curious if under your definition of "http router" that box is
terminating the ssl connection and forwarding to different backends or if
you are speaking about the non-ssl case.
On Apr 2, 2012 3:20 PM, "Poul-Henning Kamp" <[email-masked]> wrote:

> In message <CAA4WUYg79y39s3M=
> [email-masked]>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 2 Apr 2012 16:18:43 +0200

On Mon, Apr 2, 2012 at 3:36 PM, Amos Jeffries <[email-masked]> wrote:

>> It's unclear to me the point that you're making. Above, Peter said "Since
>> a SPDY session is associated with a single TCP connection, we can assume
>> all GETs on that connection are being routed to the same web server." to
>> which you said "I think that is an unwarranted assumption."
>>
> not a valid one. Transparent multiplex/aggregation/load balancer proxy is
> just three types of intermediary which violate that assumption, and we have
> not got anywhere near the more complex things like TCP splitters. SPDY
> using TLS avoided many of them so far, whatever gets approved they will
> likely all be updated to hook into the HTTP/2 protocol like they do HTTP/1.

Yes yes, totally agreed here. It clearly could be an intermediary.

> Assuming that the host can be bound to the TCP layer details prohibits all
> types of multiplexing, virtual hosting and intermediary pipelining from
> being done in the middle. The net result of that is to cap ISP at around
> concurrent 64K pipelines per box, with each restricted to only one origin
> servers traffic. That is an unreasonably low limit.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 14:36:33 +0000

In message <[email-masked]>

>you are speaking about the non-ssl case.

That's actually an interesting question.

One option, which I personally really like, is that we use a toplevel
"container" format to do multiplexing (and possibly routing), and
allow the channels to be individually TLS protected.

The nice thing about this is that we can do the upgrade to TLS using
the same TCP connection.

A mockup would look something like:

C->S	GET / HTTP/1.1
	...
	Upgrade: http-20-tls

S->C	HTTP/1.1 101 Switching Protocols

S->C	[chan=1,msg=HTTP20-REPONSE,len=X] {200|OK|Set-Cookie: blablabla...}
S->C	[chan=1,msg=HTTP20-BODY,len=X] {<HTML>yaddayadda...}
S->C	[chan=1,msg=HTTP20-BODY,flag=FINAL,len=X] {..yaddayadda</HTML>}

C->S	[chan=2,MSG=TLS-SETUP,len=X] {start TLS negotiation}
S->C	[chan=3,MSG=TLS-SETUP,len=X] {TLS negotiation reply}
...TLS negotiation completes for chan=2 

... more unprotected objects may be pulled over chan=1 in the meantime

C->S	[chan=2,msg=HTTP20-REQUEST,flag=TLS,len=X] {TLS(request)}
S->C	[chan=2,msg=HTTP20-REPONSE,flag=TLS,len=X] {TLS(reponse)}
S->C	[chan=2,msg=HTTP20-BODY,flag=TLS,len=X] {TLS(body part 1)}
S->C	[chan=2,msg=HTTP20-BODY,flag=TLS,FINAL,len=X] {TLS(body part 2)}

If we do something like that, the HTTP-router does not have to terminate
the TLS in order to route the traffic, provided the routing criteria
is available outside the TLS protection.

But of course it is still possible to terminate the HTTP at the
HTTP router if that is desirable.

A variation of the above is to do the TLS setup on channel=0 and
allow all channels to flag individual containers for SSL protection
in that TLS session, simply by setting the TLS flag in the container,
but not mandate that they do so.

This would allow secure sites to limit TLS processing to those
components of the webpage which actually needs it.  (How that
is indicated graphically to the user is also an interesting
question).

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 14:39:53 +0000

In message <[email-masked]>, Amos Jeffries writes:
>On 3/04/2012 12:10 a.m., William Chan (é™ˆæ™ºæ˜Œ) wrote:

>from being done in the middle.

Not to mention the reasons certain Google personel have communicated
in private for that aspect of SPDY's design:

	"It keeps the telcos out of our bits."

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 07:41:32 -0700

>        "It keeps the telcos out of our bits."

If you're going to say Google said this, please attribute it to a specific
person.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 14:48:39 +0000

In message <CABaLYCuzzjvuDk++QfWvhdQVTA=[email-masked]>

>If you're going to say Google said this, please attribute it to a specific

Yes, if I was going to say that Google offcially said this, I would
of course have attributed it.

Since I didn't, you should probably consider it merely a rumour.

Anything else I can help you with in the department of source-critique ?

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Mon, 2 Apr 2012 07:52:06 -0700

I didn't mean to suggest that. Rather, I was responding to your assertion
that "But the basic HTTP-router just needs to figure out which
webserver this goes to and the primary criteria seems to be:
       Host: / URI pattern match / session-cookie"

What i was getting at is that if your "http router" is also doing SSL
termination, it's keeping an SSL context around and doing nontrivial
operations on the data already, at which point I'm not sure of the
tradeoffs involved in trying to pull "routing" information further up.

As for creating multiple SSL contexts for each "stream" / "channel" in the
über TCP connection, now on the client you're keeping multiple SSL contexts
around, not clear what you are proposing for compression contexts, and
whether that involves additional roundtrips, etc.

Re: which items need to be encrypted, on an HTTPS page, everything on the
page needs to be encrypted, so there's really no signaling involved...

On Mon, Apr 2, 2012 at 7:36 AM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>

---

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

In message <CAF4kx8dt=[email-masked]>
, =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes:

>termination, 

The architecture right now does not allow routing without TLS termination,
and that is a major bottleneck for high-traffic sites.

What I tried to sketch out, was a way to allow routing without terminating
the TLS session, in order to reduce the processing load on the router.

This would allow deployment of HTTP routers in front of TLS certificates
you don't have access to, something data centers and web-hosting
companies might appreciate.

>page needs to be encrypted, so there's really no signaling involved...

I agree that with respect to man-machine interface, that is probably
the correct starting point.

But I can imagine a lot of situation where a more granual approach
would work better:

	Get http://video-on-demand.example.com/
	redirects to TLS protected login.example.com
	user logs in on TLS protected page
	user picks video on TLS protected page, get DRM key back.
	DRM protected video is streamed without TLS protection.

The actual video might even come from a different server than
the TLS session, if a HTTP router was deployed, but the client
still sees just one TCP connection.

But as I said:  There is a lot of clarity to be had with an
all-or-nothing approach to TLS.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 08:09:00 -0700

> Since I didn't, you should probably consider it merely a rumour.

We need to start ripping each other apart by posting unsubstantiated
rumors.  Facts or silence, please.

Mike

---

From: Brian Pane <[email-masked]>
Date: Mon, 2 Apr 2012 08:10:38 -0700

> S->C    [chan=2,msg=HTTP20-BODY,flag=TLS,FINAL,len=X] {TLS(body part 2)}

In terms of performance, that's a step backwards from SPDY in two ways:

- An additional round trip is needed to negotiate the use of HTTP/2.0.
You can't rely on TLS NPN if you're not doing TLS negotiation at the
outer (TCP connection) level.

- You'll have to do up to N-1 additional TLS handshakes to get N
secure streams on that connection.  I say "up to" because the client
can avoid those handshakes by choosing to wait for TLS negotiation to
finish on one channel and then use session resumption on the other N-1
channels...but that means adding 3 RTT of latency to those N-1
channels (2 RTT for the first channel to do its SSL negotiation, and 1
more round trip for each additional channel to do session resumption).

Brian

---

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

In message <[email-masked]>

>Facts or silence, please.

Well, you're @Google:  Wouldn't it be much faster to get to facts
if you declared, as appearnt official Google spokesman, that there
is absolutely nothing to this rumour ?

I'd probably take your word for it.

---

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

>- An additional round trip is needed to negotiate the use of HTTP/2.0.

You mean that it suffers from being interoperable with HTTP/1.1 ?

I don't see that as a shortcoming, I see that as a requirement
in the WG charter...

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 2 Apr 2012 17:17:45 +0200

On Mon, Apr 2, 2012 at 5:15 PM, Poul-Henning Kamp <[email-masked]>wrote:

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

Mike's not @ Google. He left awhile back.

---

From: Brian Pane <[email-masked]>
Date: Mon, 2 Apr 2012 10:48:42 -0700

> You mean that it suffers from being interoperable with HTTP/1.1 ?

SPDY also is interoperable with HTTP/1.1 -- it can cleanly SSL-tunnel
through intermediaries -- without adding that extra round trip.

-Brian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Apr 2012 15:02:39 -0400

> I'd probably take your word for it.

PHK - 

I'm not sure how much you've worked in the IETF before, but we don't have official spokesmen here. We're all speaking as individuals, and making judgements as the same. 

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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:40:56 +0000

------ Original Message ------
From: "Ian Fette (イアンフェッティ)" [email-masked]
>terminating the ssl connection and forwarding to different backends or 
>if you are speaking about the non-ssl case.
  
SSL/TLS is an orthogonal issue.  Even in SPDY we are assured it's 
optional.
  
The router is just something that forwards/routes HTTP messages, 
currently mostly a reverse proxy.
> "Since a

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:52:39 +0000

------ Original Message ------
From: "Brian Pane" <[email-masked]>
>outer (TCP connection) level.
  
no, it's not an additional RT, it's not wasted, it was a GET, and the 
response can actually be sent back with the upgrade.
  
NPN certainly is nice, but requires TLS with NPN extensions.
  
>more round trip for each additional channel to do session resumption).
Some of these could be piggy-backed.  But I think the idea is just a 
general mux layer over TCP, so the endpoints would sort it out much the 
same way they do now.
  
An alternative could be 2 connections between peers, 1 with TLS, one 
plain, and route messages accordingly.
  
I'd actually be quite keen to allow for the possibility of responses 
coming back a different connection than they were sent on, but it adds 
some challenges, mainly to do with addressing etc.
  
Adrien

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:56:36 +0000

------ Original Message ------
From: "Brian Pane" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 3/04/2012 5:48:42 a.m.
Subject: Re: Ascii-based SPDY "compression" idea
>through intermediaries
  
for now.
  
> -- without adding that extra round trip.
>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 11:11:15 +1200

On 03.04.2012 08:56, Adrien W. de Croy wrote:
> From: "Brian Pane"
>>On Mon, Apr 2, 2012 at 8:16 AM, Poul-Henning Kamp wrote:
>>
>>>
>>>In message 
>>> <[email-masked]>
>>>, Brian Pane writes:
>>>
>>>
>>>>

Speaking for Squid we already decrypt CONNECT tunnels for content 
filtering and intercept TLS connections on arbitrary ports for same. 
AFAIK, Squid was one of the last proxy intermediaries to add this 
capability.

I would not be overly surprised if installations with those features 
enabled were the 10-15% of failed/broken connections that were referred 
to earlier in reference to pipelined Upgrades, due to SPDY and 
WebSockets native support not being present in the middleware handlers 
yet.

AYJ