Re: HTTP router point-of-view concerns

"Ludin, Stephen" <sludin@akamai.com> Fri, 12 July 2013 16:33 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F77C21F9684 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 09:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeW4qrV2lF3b for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2013 09:33:21 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2C21F9F5B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2013 09:33:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UxgGy-0006nI-Fd for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2013 16:32:44 +0000
Resent-Date: Fri, 12 Jul 2013 16:32:44 +0000
Resent-Message-Id: <E1UxgGy-0006nI-Fd@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <sludin@akamai.com>) id 1UxgGq-0006iX-Qc for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2013 16:32:36 +0000
Received: from prod-mail-xrelay06.akamai.com ([96.6.114.98]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <sludin@akamai.com>) id 1UxgGp-0008HA-WD for ietf-http-wg@w3.org; Fri, 12 Jul 2013 16:32:36 +0000
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2634D165415; Fri, 12 Jul 2013 16:32:10 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 1805916540D; Fri, 12 Jul 2013 16:32:10 +0000 (GMT)
Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id CED082FD51; Fri, 12 Jul 2013 16:32:09 +0000 (GMT)
Received: from USMBX2.msg.corp.akamai.com ([169.254.1.88]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Fri, 12 Jul 2013 11:32:09 -0500
From: "Ludin, Stephen" <sludin@akamai.com>
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>
Date: Fri, 12 Jul 2013 11:32:02 -0500
Thread-Topic: HTTP router point-of-view concerns
Thread-Index: Ac5/HVqmyZ6ojZOSTqOdziV3LxFOCg==
Message-ID: <CE057AD4.46A16%sludin@akamai.com>
In-Reply-To: <20130712125628.GC28893@1wt.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Received-SPF: none client-ip=96.6.114.98; envelope-from=sludin@akamai.com; helo=prod-mail-xrelay06.akamai.com
X-W3C-Hub-Spam-Status: No, score=-3.6
X-W3C-Hub-Spam-Report: AWL=-3.297, RP_MATCHES_RCVD=-0.303
X-W3C-Scan-Sig: maggie.w3.org 1UxgGp-0008HA-WD 706ae9ff3cf3dd0672c1461f259dd73c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP router point-of-view concerns
Archived-At: <http://www.w3.org/mid/CE057AD4.46A16%25sludin@akamai.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18729
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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.

+1.  

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.

>
>Regards,
>Willy
>
>