Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

Willy Tarreau <w@1wt.eu> Thu, 08 September 2011 21:04 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E0121F8B29 for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 14:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level:
X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=-1.904, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
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 8Hb+cgHGAGMc for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 14:04:22 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE7C21F8B10 for <hybi@ietf.org>; Thu, 8 Sep 2011 14:04:22 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p88L62Gx027385; Thu, 8 Sep 2011 23:06:02 +0200
Date: Thu, 08 Sep 2011 23:06:02 +0200
From: Willy Tarreau <w@1wt.eu>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Message-ID: <20110908210602.GC27297@1wt.eu>
References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> <0fc901cc6878$1681eec0$0a00a8c0@Venus> <CAH9hSJb2rH+fX0AnekYxsEkHKzb15aHrg_hDQw1baWLiWBF-3w@mail.gmail.com> <17b501cc6d31$3016d6d0$0a00a8c0@Venus> <C2CBF8E1-ADC8-48F9-AB82-B98151A36A81@bbn.com> <634914A010D0B943A035D226786325D422C0F6D564@EXVMBX020-12.exch020.serverdata.net> <CAO228Ns7HDhRFusX7z5uGxwudp7Vj+BnE2A=Pg_oSwU4f80ExQ@mail.gmail.com> <634914A010D0B943A035D226786325D422C0F6D6AF@EXVMBX020-12.exch020.serverdata.net> <CALkdAkgGQ+CGOSWD2o3Jo-0+bXexyKUHE-BV-O4K6-m+J5NZrg@mail.gmail.com> <01D8A597-5189-4E98-9E22-0AA1ACAE6A4F@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <01D8A597-5189-4E98-9E22-0AA1ACAE6A4F@bbn.com>
User-Agent: Mutt/1.4.2.3i
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 08 Sep 2011 21:04:23 -0000

On Thu, Sep 08, 2011 at 10:57:54AM -0400, Richard L. Barnes wrote:
> Keep in mind, though, that the server still has to *un-mask* the frames from the client, which has the same cost as masking.  So you don't eliminate the performance burden on the server by removing s2c masking.  Or, equivalently, the server gets a performance benefit if clients don't mask.

It is expected that (like for HTTP), when masking performance matters,
most of the traffic will be emitted by the servers. Being able to send
a video using sendfile() is more important than saving the 100 CPU
cycles needed to decode the request for that file.

At the protocol level, there is no need for any relation between the
direction and the choice of masking. This is purely a concern of the
implementation. Basically if you're in a browser, you must mask outgoing
frames to avoid being abused. If you're a public server, you must ensure
that incoming frames are masked for the same reason. That might very well
be a config option in some products so that this can be either disabled
or changed in specific environments.

There is no reason to make it forbidden at the protocol level to use or
not use masking in either direction. The protocol consists in framed
messages and frames may be masked. It's a lot easier if the frames
decoders are always the sames, so in practice you won't gain anything
by trying to enforce an asymetry.

The cost of running the XOR is negligible, as was shown by measurements
months ago. Even a not-so-modern desktop machine has no trouble XORing
at 10 Gbps.

In fact, I think that the reason why we're starting to see this mask/unmask
discussion now is that implementations are progressively taking place and
developers wonder whether they can get rid of something they think is
useless so that it's even easier to write the code. Maybe the draft still
lacks some explanations, maybe even some code examples (though I think
that the masking/unmasking algo is clear enough).

Maybe providing code examples which handle both masked and unmasked frames
would reduce the number of questions, I don't know.

At this stage, it would be nice if people would focus on how to make the
draft more understandable for everyone instead of trying to restart a year
of long debates with the questions that were discussed long ago.

Regards,
Willy