Re: Adjusting our spec names

In message <CAP+FsNdSw8HMTcTmk7Z6VE9yXnQjZtMwGL1iEwQuSGG0-VPKuA@mail.gmail.com>
, Roberto Peon writes:

>> We saw this very clearly with crypto-offloading, for instance HiFns
>> chips, where the cost of the setup was so high that in many cases
>> it was faster to just do the crypto on the CPU instead.
>
>Not having played with Hi/FNs stuff, I don't know where the problems lay,

No screw-up, the HiFn crew were pretty smart people.

Its simply that the distance from a userland application that needs
crypto, down to the kernel and out to a PCI device takes a devastating
amount of time, relative to the actual crypto operation.

Footnote:

	VIA went and did what should be done: they added AES as a
	CPU instruction, exploiting politics the same way ZyXel did
	in the 1990ies, when they added 3DES to their modems.

	Rumours has it that Intel and AMD have CPU hardware have
	supported crypto-instructions for several years, but that
	the necessary microcode-update file is "Teserved for certain
	customers only."

What Intel now does with offloading into the ethernet-chips is
similar to what IBM did with the 3745 Mainframe Frontend back in
the 1980ies.  The words "desparate" and "futile" were used a lot
about it in the early 1990ies.

>> Right now everybody is scrambling to show that they can handle
>> full packet load at 10Gb/s and 40Gb/s.
>
>>From what I've seen, the CPUs aren't the bottleneck, it is the architecture
>>of the IO subsystems of our OSs and often a lack of multiqueue on the NICs.

Well, as I hinted above, the evolution of the IBM mainframe is very
enlightening here, we see the exact same order of developments in
the PC platform these days:

	More complex and specialized instructions are added
	More parallel execution units rather than faster EUs
	More and larger caches to cover speed disparity EU<-->RAM
	Virtualization to get better utilization of numerous EUs
	EUs move further and further away from I/O units
	I/O Units gain more and more processing power to compensate.

I think this may be a law of nature of sorts, a curse which tangle
up any successful machine architecture.  If you look at the Thumb2
instruction set, ARM seems to be headed down the same deroute.

So no, I don't put much trust in processing offload: It's complicated
to implement both in hardware and software , it has high latency
an the performance gain is only very slight.

But it will probably be done anyway.

The most we can do, is make the protocol sensible for it.

>To be clear, my opinion is that we can lay the groundwork on which a change
>of semantics is built (e.g. from request->response to more arbitrary
>message<->message or message<->stream mappings), but that attempting to
>define those semantics here and now will make it less likely for the entire
>effort to succeed.

I think the prudent thing would be to design the new
serializations/transports for "message<->message", to be future
compatible, and use them only for the subset functionality of
"request->response" for now.

>> The performance bottleneck is not going to be the endpoints, but rather
>> the points along the path where traffic from many sessions
>> is aggregated:
>>
>>        The telcos outgoing mobile->HTTP proxy
>>        The load-balancer of $bigsite
>>
>
>imho, from the point of view of the client, the load-balancer of $big-site
>or any other reverse-proxy is likely the endpoint as viewed by the client.

Yes, that's what makes it the bottleneck, but in protocol terms the
endpoint is where a request gets replied to with a response.

>> HTTP/2.0 should have real sessions, so that HTTP-routers don't have
>> to inspect and mangle cookies.
>
>Defining sessions may be ok, so long as discrimination against various
>endpoints can be accomplished by intermediaries only when the user has
>given them permission to do so.

I have read draft studies that showed that you could tell when
people where typing their password over a SSH connection, based on
the timing of the packets.  The timing pattern eliminated about 50%
of the entropy from the password typed, due to the constraints in
the QWERTY layout.

Privacy is a _lot_ harder than most people think.

I think we need to have a realistic view of what level of privacy
can be guaranteed, and I would like to see us move to a model
more like email, where you have a plain-text envelope used for
routing and the (optionally) privacy protected content.

I would argue, that for HTTP the request envelope consists of:
	request (GET/POST...)
	URI (maybe without the query part ?)
	Host:
	Session identifier (today a cookie)
	Length of transmitted body, if any.
For reponses the envelope is only
	status code (200,503,...)
	session identifier
	Length of transmitted body, if any.

This should make the "HTTP-router" people happy and shield them from
semantic interpretations.

>Perhaps the wg (i.e. we) should do an analysis of motivation and incentives
>for forward/reverse proxy and other intermediaries? Understanding the game
>theory would be helpful for everyone and would inform decisions that are
>more likely to benefit everyone in the long-term.

I second that.  It's quite clear that there are some divisions now
as evident in the "Mandatory TLS" vs. "You got to be kidding!"
factions.  Settling those "ideological" differences before we dive
into bits and bytes can and will save us time and conflicts down
the road.

I think at the end of the day, its rather simple though:

1) Clients should know if and when they have end to end privacy.

2) Clients should know when they have positive authentication
   of the server. (Can the client trust the server)

3) Servers should know when they have positive authentication
   of the client. (Can the server trust the client)

4) Servers should have access to means of client identification.
   (eg: For load-balancing, so all requests from the client end up
   on the same server)

5) Proxies should be able to enforce content-inspection, and
   possibly content-modification, but users should be made clearly
   aware that this happens (ref: 1)  In this case 2 & 3 applies
   to the client-proxy relationship.

6) Seen from the server-side, proxies come in "trustworthy" (server-side
   reverse proxy/http-router), "suspect" (3rd party CDN) and
   "untrustworthy" (forward/client side), with respect to their
   willingness to follow instructions from the server.
   (For instance about object validity lifetime or cacheability.)

>It doesn't matter if my site and LB can do 1Tb/s if AT&T decides to
>throttle my site [...]

The extended OSI model indicates that this is a layer 8 (politics)
problem.

Trying to solve it a lower layers doesn't work and should
not be attempted.

>I think it is important for the transition period, where people deploy
>reverse proxies or loadbalancers which speak HTTP/2.0 to the client over
>the large-RTT net segment and then speak HTTP/1.1 to their backends until
>they eventually upgrade.

That's one of the primary reasons why I want to keep HTTP/2.0
request->response for now.

It's important to realize that the 1.1 <-> 2.0 conversion does not
have to be 100% perfect in all aspects, it just has to be semantically
perfect, which is a much lower bar to clear.

-- 
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 Sunday, 1 April 2012 23:56:26 UTC