Van Catha <vans554@gmail.com> Fri, 30 September 2016 21:21 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 []) by ietfa.amsl.com (Postfix) with ESMTP id C6BD112B177 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Sep 2016 14:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.836
X-Spam-Status: No, score=-8.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Z_pwkXTgFMJC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 30 Sep 2016 14:21:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF9212B005 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 30 Sep 2016 14:21:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bq5BR-0001tp-TE for ietf-http-wg-dist@listhub.w3.org; Fri, 30 Sep 2016 21:17:29 +0000
Resent-Date: Fri, 30 Sep 2016 21:17:29 +0000
Resent-Message-Id: <E1bq5BR-0001tp-TE@frink.w3.org>
Received: from maggie.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bq5BB-0001rC-Un for ietf-http-wg@listhub.w3.org; Fri, 30 Sep 2016 21:17:13 +0000
Received: from mail-qk0-f171.google.com ([]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <vans554@gmail.com>) id 1bq5B2-0006W1-4o for ietf-http-wg@w3.org; Fri, 30 Sep 2016 21:17:05 +0000
Received: by mail-qk0-f171.google.com with SMTP id n189so45709876qke.0 for <ietf-http-wg@w3.org>; Fri, 30 Sep 2016 14:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=McCf3nG27yHVaMVXpM4BLWwR6dySMB9pV9VwaydRcJo=; b=tcNWUzzYXwrtmAU5n6elz7ScrCfjNjLeXOT6vYeeZiSBmAKlzVTKft0fSj6Exut98o fNk/XR/D792+3YgtyxUgIrdWhUqD7jO/oEc4gzOs+//w6PbcTnh3ArFHZTqTzCFgtM8t 22zjEVDFbdFwqXqf2b08+3uwXQPlDPt3B0ny7+saKcu69w8aYTPbYRT8ErMr2COxes27 HgrQQIfSHzdkvsP/lE9/POidG4/5uaeDPWByKN6Ch9YqtSbE+k0UulJAUDbVLR1KBKg3 J4we6RSYvKbSq/07TQixAdnx/7P8WpX5bZdTSFh41MzNspRX9aecj+j619oWi2ZRHAAB PtTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=McCf3nG27yHVaMVXpM4BLWwR6dySMB9pV9VwaydRcJo=; b=D4awiySseXRIqAuMf0es3PTqnRIZzicL6Du+8DxW6XyYUuexvZKsod5UWGsOIV6Rdu nKpI8uSelL0VAODifOt0FR0P+NnFO+TF1AnjE6/UL9qs6hUFtUMODJTBWrQoLgdYV2fU rxNX/Qus4VkvVLsEq7Arnz5nCNiv5LOdGY5GMJrF26OjPv+/wiT/D748+HYHxgKCHAyU gnsw9gI+zZt7l4PSkavyju2yvy2xM5Fw3VtQ73KvVr+NVzesENzDjrsxH0bvo4y/Rcbp kNEY+58aoBBn34U91b5dF5iDmp1lhVZFFLHRF2xdUepPXhWZXEc/e8AMBnPZWtWLK4lL xkew==
X-Gm-Message-State: AA6/9RlxS57uFfnZpXSKgUUm6L5hlFCC9U1DCk235c21jQ27aqcIkx6h421bHwjvAZODMQL4KZ2gS/rRHNPVzw==
X-Received: by with SMTP id t123mr3770189qkd.130.1475270197879; Fri, 30 Sep 2016 14:16:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 30 Sep 2016 14:16:37 -0700 (PDT)
From: Van Catha <vans554@gmail.com>
Date: Fri, 30 Sep 2016 17:16:37 -0400
Message-ID: <CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com>
To: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary=94eb2c081fee17aad5053dc01cd8
Received-SPF: pass client-ip=; envelope-from=vans554@gmail.com; helo=mail-qk0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-1.0
X-W3C-Scan-Sig: maggie.w3.org 1bq5B2-0006W1-4o dd55d21dac1c43460581f26b2dd4ab0a
X-Original-To: ietf-http-wg@w3.org
Subject: WebSocket2
Archived-At: <http://www.w3.org/mid/CAG-EYCjx5=tExsjOJ+_-5p95Vp=Wfaz8JihDAAykDQpL64T4TA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32430
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>

Continuing from the Google group

I drafted up a rough RFC to support WebSocket2

There are some pain points that I hope can be sorted out; if of course this
is of interest.

To answer some questions that were asked on the Google group:

Daniel Stenberg asked:
-- The compression negotiation seems very complicated, do clients/servers
really need that extreme flexibility with levels and bits?

For lz4, really only level 1 and 9 is needed.  But supporting in between
adds some flexibility without really compromising anything.  Removal of
support for comma separated values is indeed complex. It has been removed.

Lz4=1 uses barely any CPU and provides solid reduction in final size.
Lz4=9 uses about as much CPU as deflate (under best_compression) with
substantial reduction in final size.

For deflate, the sliding window makes a huge difference. From
you can see the amount of memory taken.

        compressor = (1 << (windowBits + 2)) + (1 << (memLevel + 9))
      decompresser = (1 << windowBits) + 1440 * 2 * sizeof(int)
             total = compressor + decompresser

So with a window size of 15 bits you need at least 131kb, with compression
level 8 another 131kb, plus decompresser. Your looking at around 300kb per
connected peer.  With a window of 8 bits and memory level 1 the memory
requirements significantly drop to 15kb~ per peer, also you can tune the
memory level on the server without breaking the client. So you can have 20
times more peers.

This is the difference between taking 30GB of ram for 100,000 peers, and
30GB of ram for 2m peers.  Tuning in between will allow you to find a sweet

To make the compression even simpler its possible to only allow lz4=1,
lz4=9 (aka lz4hc), but for deflate sliding windows, it really needs to be
customizable IMO.

A service like WhatsApp would be interested in worst compression ratio but
more long living concurrent connections per server, so for them a 8 bit
deflate window might be good.

A real time game for mobile like Clash Royal would be interested in a
deflate window of 15 bits, as they need to make sure data is as compressed
as possible so it arrives as quickly as possible on low bandwidth channels
like 3G.

A service like Dropbox would be interested in lz4=9, as this would greatly
speed upload and download of uncompressed files such as raw images and text

A service transmitting pixels and input under low latency such as
TeamViewer would be interested in lz4=1 as the compression throughput is
very high and ratio is often at least 2x.

-- A 501 response code for not accepted feels weird as I don't think its
the server's fault. I would expect a 4xx code. Maybe just 403?

The response codes returned really need work. 403 does look appropriate. I
am thinking the response should carry an extra header with the 403 if an
error occurred, websocket2-error perhaps?  To give details on the exact

Lucas Pardue asked:
-- What is the benefit of the payload size field defined in section 4?

This is only for when HTTP/2 is also the transport layer.  HTTP/2 has a max
DATA frame size an endpoint is willing to receive set by the end points
during negotiation (SETTINGS_MAX_FRAME_SIZE), it has a minimum value of
16,384 and max of 16,777,215.  A websocket frame must be presented as 1
full message to the client API.  The client API has no way to know the true
final size of the full message.  Using QUIC I believe you can set a frame
length up to a 64 bit unsigned long with no restricted maximum, so this is
open to debate on the best way to do it.