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

Iñaki Baz Castillo <ibc@aliax.net> Wed, 27 July 2011 10:46 UTC

Return-Path: <ibc@aliax.net>
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 318B521F8B11; Wed, 27 Jul 2011 03:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Level:
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 1+6qokdm2qMO; Wed, 27 Jul 2011 03:46:29 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31BDB21F8B10; Wed, 27 Jul 2011 03:46:29 -0700 (PDT)
Received: by qwc23 with SMTP id 23so968325qwc.31 for <multiple recipients>; Wed, 27 Jul 2011 03:46:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.1.8 with SMTP id 8mr4190185qcd.215.1311763588455; Wed, 27 Jul 2011 03:46:28 -0700 (PDT)
Received: by 10.229.224.212 with HTTP; Wed, 27 Jul 2011 03:46:28 -0700 (PDT)
In-Reply-To: <20110727101757.GA6586@1wt.eu>
References: <CAP992=GedTEfimykCWwdwm=BsZdwFRJO36EO0a_o7iejURJ+tQ@mail.gmail.com> <CALiegfnwNyYDy=SyrqHJXV0ZreADb7F8QySvgdHofW9Hm9miZQ@mail.gmail.com> <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>
Date: Wed, 27 Jul 2011 12:46:28 +0200
Message-ID: <CALiegfmMO2Es6P=qy4m=XULVQE9bDp7S0LYXG_9n4Lk9yirGXQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 10:46:30 -0000

2011/7/27 Willy Tarreau <w@1wt.eu>eu>:
> That's where I think you're mistaken. As long as you think of it as mandatory
> this will not be possible.

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

So assuming that SRV is optional for clients, the provider does not
know how many clients would use SRV or just A. 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.

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.

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").

Also the fact that DNS is not mandated by HTTP neither WS makes things
even worse. 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.

Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>