Re: [hybi] Websocket success rates and TLS extension.

Justin Erenkrantz <justin@erenkrantz.com> Sat, 17 April 2010 07:52 UTC

Return-Path: <justin.erenkrantz@gmail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD813A6AFB for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 00:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.459
X-Spam-Level:
X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxx2DX1Tu8V9 for <hybi@core3.amsl.com>; Sat, 17 Apr 2010 00:52:24 -0700 (PDT)
Received: from mail-qy0-f171.google.com (mail-qy0-f171.google.com [209.85.221.171]) by core3.amsl.com (Postfix) with ESMTP id 98B003A6AFA for <hybi@ietf.org>; Sat, 17 Apr 2010 00:52:24 -0700 (PDT)
Received: by qyk1 with SMTP id 1so3311264qyk.15 for <hybi@ietf.org>; Sat, 17 Apr 2010 00:52:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=A/gX4tYjHWxhh6BwulY2vFgaUY9g/3X7zeXNhGbS2kc=; b=eaVyC8oBkUF6bK1/MWe5LzgzG0LfDMe5BXhTydKECA1pKV6ZkHYEqJv86HiFSugblQ lmcl/Nc5qnt7kPV0zP+Q9XopVGnqkxttS6wDCRMGTZAglikezBj3k2wkOOfbwGEyhR+p jT1/iY4M8hzzCvKjvnmGW0fNE5jw6Tz1ZzEuI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=XD6C3wqe7vvnCkCYHBAasZAgPDfMTb/e3OyWBsysFUwAChx+RLDWjNEyzW2ZLzjTNm lyUGWXIj9XmFE5jYceXVy6H0UjeN+M/X5RHDkbyVidWRPBbVrVbl6ZhSr9SmSUXPYvgO e/hJ6wc1g7wyaZtepRgNRfWGZwsQUHuMARAr4=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.229.17.84 with HTTP; Sat, 17 Apr 2010 00:52:17 -0700 (PDT)
In-Reply-To: <x2x2a10ed241004160156s6293d2cak482a1b0bde412ef1@mail.gmail.com>
References: <4BBAECB7.2030009@webtide.com> <q2q5c902b9e1004152341l8a877521yb69c3230bb8e953c@mail.gmail.com> <x2x2a10ed241004160156s6293d2cak482a1b0bde412ef1@mail.gmail.com>
Date: Sat, 17 Apr 2010 00:52:17 -0700
X-Google-Sender-Auth: ab2a88e337d48581
Received: by 10.229.191.15 with SMTP id dk15mr3762742qcb.20.1271490737114; Sat, 17 Apr 2010 00:52:17 -0700 (PDT)
Message-ID: <x2h5c902b9e1004170052z5dd7015seb6e430a87fdb710@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Mike Belshe <mike@belshe.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Websocket success rates and TLS extension.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Apr 2010 07:52:25 -0000

On Fri, Apr 16, 2010 at 1:56 AM, Mike Belshe <mike@belshe.com> wrote:
> So back to Greg's note:  the current websocket handshake requires a RT, and
> it will be difficult to use websocket for low-latency uses which it has
> that.  We're pretty sure that a low-latency protocol needs to remove more
> RTs.  But perhaps there is something genius yet to be discovered :-)

To just (re)state the obvious - if there is some extra bit coming
along with the TLS handshake (such as the extension Greg pointed at),
I think that'd reduce the RTs - or at least not add an additional one
on top of TLS.

To restate it even more verbosely...it'd be pretty straightforward for
a client that sticks a Web Socket handshake (or something) in the
tlsext for httpd/mod_ssl to immediately operate as if the upgrade is
successful.  Obviously, if you're talking to a server that doesn't
understand that tlsext, then you'd have to fallback to the GET
Upgrade: request mechanism.  But, it'd give us a nice opt-in for
latency reduction if both sides support the optimized sequence.

I do like this idea...  -- justin