Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Willy Tarreau <w@1wt.eu> Wed, 27 July 2011 12:45 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 EF9C921F84F1; Wed, 27 Jul 2011 05:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[AWL=-2.476, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBNzcz2f6qyV; Wed, 27 Jul 2011 05:45:53 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id EE1A721F84EB; Wed, 27 Jul 2011 05:45:52 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6RCjj97006977; Wed, 27 Jul 2011 14:45:45 +0200
Date: Wed, 27 Jul 2011 14:45:45 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110727124545.GA6931@1wt.eu>
References: <CABLsOLCgxDNDs54GUybBzmG8a6rNPzXzFcwf_OU25j5L+AobaQ@mail.gmail.com> <CALiegfnp+kNqnU-_x2ZBZnN8fzP=4+6WO=QPjw1rJzvZmSXEAg@mail.gmail.com> <20110724185949.GB22405@1wt.eu> <9031.1311538720.416128@puncture> <20110724204236.GG22405@1wt.eu> <CALiegfkgukeaiMR-Yc15qUJYCB-KPcoNoX4G6NrN4+DOiDS+tw@mail.gmail.com> <20110726192850.GB3692@1wt.eu> <CALiegfndubt3xgRLFWUikhizsvX60p4+b0DcouX0_m5B8vestg@mail.gmail.com> <20110727101757.GA6586@1wt.eu> <CALiegfmMO2Es6P=qy4m=XULVQE9bDp7S0LYXG_9n4Lk9yirGXQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALiegfmMO2Es6P=qy4m=XULVQE9bDp7S0LYXG_9n4Lk9yirGXQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Server-Initiated HTTP <hybi@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
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: Wed, 27 Jul 2011 12:45:54 -0000

On Wed, Jul 27, 2011 at 12:46:28PM +0200, Iñaki Baz Castillo wrote:
> Hi Willy, as I've explained several times in these threads, if a WS
> client is not mandated to perform SRV given a WS URI domain, then the
> service provider cannot rely on SRV records. This is, let's assume
> that a WS service provider offers a WS URI like "ws://mydomain.org",
> with these records (simplifying):
> 
> - SRV:   1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90
> - A:        1.1.1.1

No, he would have :

 - SRV:   1.1.1.1:80, 1.1.1.2:80, 1.1.1.3:90
 - A:     1.1.1.1, 1.1.1.2, 1.1.1.3

> So assuming that SRV is optional for clients, the provider does not
> know how many clients would use SRV or just A.

That's mainly the point : the provider would offer a service which is
designed to work both ways and which a part of the users would experience
better due to their consideration of the SRV record.

> Imagine the service
> provider expects millons of concurrent users. He must be ready to
> receive all those users in 1.1.1.1 (if they don't use SRV). So the
> service provider must build a complex/expensive balancer system in
> server side (BGP and all that stuf) just for the case in which most of
> the clients would not perform SRV procedures. So 1.1.1.1 would be in
> fact a balancer with N hosts providing the WS service behind it.
> 
> At the same time, if clients use SRV then load-balancing and failover
> would be automatically provided by the SRV capabilities. No need for
> like-BGS solutions in server side.

Once again, the goal to make SRV adopted BY USERS is not to ensure that
it tries to cover all the server-side needs, but that it offers better
quality of service to USERS. That way USERS will massively adopt it and
server will one day be able to safely rely on it. Just like neither
Javascript nor cookies nor flash are mandatory, still all of them are
very common in practice and many service providers happily rely on them.

> So the question is: which service provider would spend resources, time
> and efforts building two different load-balancing/failover systems?.
> If a provider can build the "BGP" solution then it will not need SRV.
> And another provider which cannot build a "BGP" solution could not
> entirely rely on SRV capabilities as maybe most of the clients would
> not use it.

You can't transform the Internet in one day after publishing one draft.
Look at the Set-Cookie2 header. It was a massive failure. It was thought
that the broken Set-Cookie header could be fixed by one new RFC, and
nobody adopted it. The reason is that it was proposed as a replacement.
I think that Opera might be the only browser to parse it. In contrast,
if your proposal is backwards compatible and incites users to enable it
on their side, then in a few years it can become a de-facto standard.

> In the other side, if service providers must be ready to accept all
> the traffic in the IP resolved via single DNS A query, then nobody
> would need SRV and webbrowsers would just remove it (the Mozilla
> developer has already said in these threads that he won't implement it
> "due to latency reasons").

That's why I explained that you have to find what other benefits *for
the end user* can be brought by this. End users are deciding, not site
owners.

> Also the fact that DNS is not mandated by HTTP neither WS makes things
> even worse.

That's why SRV cannot be made mandatory.

> In contrast, in XMPP and SIP protocols DNS is mandatory
> and also SRV procedures. If you are a SIP provider hosting the service
> with domain "mydomain.org" you don't ever need to have a working A
> record for mydomain.org, but just SRV (and optionally NAPTR). Or you
> could just have A record and not use SRV at all. SIP client procedures
> for locating servers (RFC 3263) mandate first trying SRV and then
> A/AAAA, so things would work in any case.
> 
> So correct me if I'm wrong, but making SRV optional for clients (in
> *any* protocol) is not something I consider feasible or useful.

Feasible yes, useful I don't know, and I'm not the one trying to argue
that it can add value. If it can bring value to the user, some users
will enable it despite the possible added latency. If it does not
bring them anything, they won't use it.

Regards,
Willy