Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

Greg Wilkins <gregw@webtide.com> Wed, 01 December 2010 19:39 UTC

Return-Path: <gregw@intalio.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 E52BE3A6C9A for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 gZGVVSvqWqJp for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:39:42 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 920E73A6C91 for <hybi@ietf.org>; Wed, 1 Dec 2010 11:39:42 -0800 (PST)
Received: by qyk34 with SMTP id 34so2918741qyk.10 for <hybi@ietf.org>; Wed, 01 Dec 2010 11:40:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.67.17 with SMTP id p17mr1645420qai.382.1291232455836; Wed, 01 Dec 2010 11:40:55 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.167.203 with HTTP; Wed, 1 Dec 2010 11:40:55 -0800 (PST)
In-Reply-To: <AANLkTimQ3bm5-2tN0QEt=qX4CR_XFpcLXF7Auz2ijo0Z@mail.gmail.com>
References: <AANLkTik0wR-Oag5YJJDmdiSy67WW6TMaHmqWEo4o5kGW@mail.gmail.com> <AANLkTimwEtKrJm5KxTYZ4wrtONBYDTGjE5LF7__AHBEU@mail.gmail.com> <20101201183540.GF19021@1wt.eu> <AANLkTi=r-is4ZqJc6itsaBkyrmW746xXj8OV78M_Qbi3@mail.gmail.com> <AANLkTimtjYUOidZcxkSEtaUniJC6m8ujzFa69DMQVhZH@mail.gmail.com> <AANLkTimQ3bm5-2tN0QEt=qX4CR_XFpcLXF7Auz2ijo0Z@mail.gmail.com>
Date: Wed, 01 Dec 2010 20:40:55 +0100
X-Google-Sender-Auth: pi9E_CxfIkta63o6q2H676Iw_68
Message-ID: <AANLkTing3grEETt4s2CVSu4BtHPXOA8_MAm=sBQpYaJx@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>, Zhong Yu <zhong.j.yu@gmail.com>
Subject: Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes
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: Wed, 01 Dec 2010 19:39:45 -0000

On 1 December 2010 20:10, John Tamplin <jat@google.com> wrote:
> On Wed, Dec 1, 2010 at 2:01 PM, Greg Wilkins <gregw@webtide.com> wrote:
>> As proposed, the Hello frames do not cost an extra round trip.
>
> Unless I misunderstood your proposal, doesn't the server have to wait
> for the client's Hello reply before it can send any messages?  That
> seems like it adds one RTT (not two, as it would be if the first Hello
> wasn't piggy-backed with the server response).'

The server can send messages as soon as it has sent it's Hello.


> I agree the Hello frames are useful in this case.  However, how often
> is this case present, and is getting a WebSocket-layer timeout rather
> than app-layer (which in most cases will have to be present anyway)
> worth the price for all the other cases?  I don't have any numbers for
> it (do you?), but my gut feeling is it is low.

I agree that Hellos may be less useful with CONNECT.  But we have to
do something about the current handshakes unframed bytes and space
encoded nonces.  If we leave the unframed bytes as they are with
CONNECT, then we will probably still have the identified issue of an
intermediary that does not forward the bytes and the server hanging
while it tries to read them.


> Except that depending on what we switch to, those things you want
> removed aren't present at all, such as in Adam's proposals.

Adam's complete proposal has other aspects to it that are not as well
accepted as trying CONNECT.

If we do agree that CONNECT is better than Upgrade, that is not a
reason to completely adopt the first proposal that uses CONNECT
without questioning each of it's elements.

The handshake is in such a mess because we accepted a big bundle of
changes after only agreeing one aspect of them. We have now spent
months talking about the removal of the additional "features" that
crept in with that batch.

> So, moving them somewhere else doesn't seem like an incremental step but
> rather wasted effort.

Incremental changes are always wasted effort if you are 100% sure you
know all the increments in advance.
The whole point of incremental changes is that you can re-evaluate
along the way and perhaps revert some changes made earlier when
considered in the light of subsequent changes.