6455 Websockets and the relationship to HTTP

Patrick McManus <pmcmanus@mozilla.com> Thu, 01 December 2016 15:52 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 C82501295E4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Dec 2016 07:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.295
X-Spam-Level:
X-Spam-Status: No, score=-9.295 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrBZniHb6IhU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Dec 2016 07:52:38 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A948E12943A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Dec 2016 07:52:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCTbW-0004j8-G6 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Dec 2016 15:48:58 +0000
Resent-Date: Thu, 01 Dec 2016 15:48:58 +0000
Resent-Message-Id: <E1cCTbW-0004j8-G6@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pmcmanus@mozilla.com>) id 1cCTbO-0004hP-Sd for ietf-http-wg@listhub.w3.org; Thu, 01 Dec 2016 15:48:50 +0000
Received: from www.ducksong.com ([192.155.95.102] helo=linode64.ducksong.com) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <pmcmanus@mozilla.com>) id 1cCTbH-0005UX-H3 for ietf-http-wg@w3.org; Thu, 01 Dec 2016 15:48:45 +0000
Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id E7FA63A01B for <ietf-http-wg@w3.org>; Thu, 1 Dec 2016 10:48:20 -0500 (EST)
Received: by mail-qt0-f180.google.com with SMTP id w33so223854647qtc.3 for <ietf-http-wg@w3.org>; Thu, 01 Dec 2016 07:48:20 -0800 (PST)
X-Gm-Message-State: AKaTC00xSrAZuHOnfLCee+VbOqYL5uiWK8FjiHXk7neQOeGYgjfCKO1MF2wrMl8wSVe4XDwNi9lDGW2jeuiG+Q==
X-Received: by 10.200.56.186 with SMTP id f55mr33377639qtc.75.1480607300601; Thu, 01 Dec 2016 07:48:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.147.78 with HTTP; Thu, 1 Dec 2016 07:48:20 -0800 (PST)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 1 Dec 2016 10:48:20 -0500
X-Gmail-Original-Message-ID: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com>
Message-ID: <CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113978b434521805429ac095
Received-SPF: softfail client-ip=192.155.95.102; envelope-from=pmcmanus@mozilla.com; helo=linode64.ducksong.com
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AC_DIV_BONANZA=0.001, AWL=-1.607, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cCTbH-0005UX-H3 96cfd155a18115d8a6d98212c92f320d
X-Original-To: ietf-http-wg@w3.org
Subject: 6455 Websockets and the relationship to HTTP
Archived-At: <http://www.w3.org/mid/CAOdDvNqk7W_oNWUismMb-ZuhvdboZNDQ0YV2BLsbka-FGC-7oA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33067
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>

Hi All.

The continued websockets discussion is interesting to me - its clear the
number of interested parties is small but significant (e.g. almost nobody
in the room in Seoul had read the presented draft, but a diverse number of
participants are making related technical contributions on the list.). The
general advice remains in effect - 6455 wasn't done in HTTPbis so its best
to seek another venue (a new wg, or perhaps dispatch help) for an update -
but when it comes to its interaction with HTTP that's on topic for this WG
and there probably is some expertise. So I don't mind the conversation
continuing as long as a parallel effort to find a home for actually
adopting the work is made.

I would like to use this thread to better understand, for my own
edification, what the problem being addressed here is and how big of a
problem it is in practice. Its not controversial to say that 6455 has
warts, and given the toolbox we have now it would be done differently - but
what in terms of operations would be improved by an update to a h2 world?
Would that be a different set of answers for a quic world?

Here's what I think I'm hearing, but there are so many messages that are
done in the weeds of the solution space I don't want to lose track of the
problems being solved - I think this list might help in any chartering
discussion:

* in a practical sense there is no mux and when you have mux you need
priority and flow control. h2 solves this.
* operational overhead of maintaining/admin h1 just to boostrap to
websockets.
* latency of a new h1 connection just to bootstrap to websockets
* operational overhead of separate conns for http and ws

is there more? some data on this stuff would be good. Is this really mostly
about mux?

I can see where the introduction of quic makes this gap even bigger.. with
its lower latency and potential to deploy more modern transport features.
It would be great to be more crisp on this - I have read
https://github.com/bidiweb/bidiweb-semantics/blob/master/SurveyOfProtocolGaps.md
and its still not clear to me what the driving concern is.

-Patrick