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

Re: HTTP router point-of-view concerns

From: Ludin, Stephen <sludin@akamai.com>
Date: Fri, 12 Jul 2013 11:32:02 -0500
To: Willy Tarreau <w@1wt.eu>, Poul-Henning Kamp <phk@phk.freebsd.dk>
CC: Mark Nottingham <mnot@mnot.net>, Sam Pullara <spullara@gmail.com>, James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CE057AD4.46A16%sludin@akamai.com>

On 7/12/13 5:56 AM, "Willy Tarreau" <w@1wt.eu> wrote:

>Hi Poul-Henning,
>On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote:
>> In message <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>, Mark
>>Nottingham wri
>> tes:
>> >This has been brought up a number of times. I think what we need is a =
>> >concrete proposal *with* a detailed plan for a workable transition to =
>> >the new mechanism -- which seems to be the (or at least one) sticking =
>> >point whenever this comes up.
>> I have given a concrete example multiple times, it's very simple:
>> 	The client always sends along a session-identifier of N (128?)
>> 	bits.
>> 	If the first bit is zero, this is an anonymous, transient
>> 	session, not (to be) associated with any other session.
>> 	If the first bit is one, this is a persistent session
>> 	identifier, which the server can use to look up any relevant
>> 	state or information from previous instances of this
>> 	session, in its local database.
>> 	This replaces the Cookie: and Set-Cookie: headers, which
>> 	SHALL NOT be sent in the HTTP/2.0 protocol.
>> Advantages:
>> 	We get a fixed size session-identifier for HTTP routers to
>> 	use for flow-routing.
>> 	We get an actual (client controlled) session-concept, rather
>> 	than all sorts of ad-hoc simulations with cookies.
>> 	Data with privacy-concerns are stored on the server not on
>> 	random clients the user happens to borrow or use.
>> 	The overhead of encrypting and signing the data in cookies
>> 	is avoided, since they are stored on the server side where
>> 	nobody can fudge them.
>> Backwards compatibility:
>> 	It should be obvious that simulating the Cookie concept for
>> 	framework compatibility on the server side is a trivial
>> 	matter of programming:  Rather than send set-cookies, write
>> 	them to a database, indexed by the session-id.  Rather than
>> 	receive Cookie: headers, look them up in the database.
>> There, solved.
>Not really in fact. While I tend to generally agree with the points
>you make for scalability, this one does not scale. One of the big
>benefits of cookies is that client is responsible for synchronizing
>information between multiple servers *if needed*. When you're building
>an architecture using anycast DNS + ECMP + L4 load balancers to reach
>your servers, you can't predict if a client will come back to the same
>place to retrieve its context, and having the ability to make it hold
>*some* data is really useful.
>If you store everything on server-side, you're forced to synchronize
>everything between all servers of all datacenters because you don't
>even know where your client will go with next hit, let alone parallel
>requests. And this is clearly not possible on many of the platforms
>where both of our products are deployed to achieve connection rates
>in the 6 digits.
>So there *is* some use to store data on the client, it's just that it
>has been long abused to store session identifiers because it was the
>only mechanism available.
>While I'd like to see a simple session management system (like the one
>you propose maybe, even if it does not cover the case of low entropy
>client devices), I don't want to see the cookies disappear. I just want
>to be able to rely on session ID without having to parse cookies when
>that's not needed.


The distributed data store that the sea of user-agents compromises dwarfs
anything we could engineer easily on the server (or proxy) side.  Though I
agree completely that there are numerous advantages to the idea of the
user-agent holding only the session 'key' and the bulk of the data being
on the server, the complexities of dealing with that in a distributed and
massive origin/proxy environment are daunting and fear would erase much of
the benefit that the distribution hopes to provide.

I just implemented the header compression spec and it felt incredibly
complex so I am definitely inclined to figure out a scheme for
simplification.  My concern is similar to Mike's: we will get buggy
implementations out there that will cause us to to avoid its use in the
long run.  The beauty of the rest of the HTTP/2.0 spec is its simplicity
of implementation.  I like to think we can get there with header
compression as well.

Received on Friday, 12 July 2013 16:32:36 UTC

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