Subject: [hybi] DNS SRV for WebSocket

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 27 Mar 2011 19:23:51 +0200

Hi, DNS SRV [*] is a mechanism for providing load-balancing and
failover at client side. It's very common in modern communication
protocols as SIP or XMPP. It's not used in HTTP, most probably because
HTTP was created before SRV records, and when SRV was specified it was
too late for including it into HTTP protocol. However WebSocket is a
new protocol and could take advantage of it.

For now, WebSocket draft just provide a host (hostname or IP) and port
for the client to communicate with a WS server. Now that WS is still a
draft it would be a good moment to include DNS SRV into WebSocket.
Please consider it.

Usage example:

- A web page includes a WS connection to some-domain.org.

- The web browser performs a DNS SRV query for
_ws._tcp.some-domain.org and gets the following SRV records:

    _ws._tcp.some-domain.org. IN SRV 1 60 80 ws1.some-domain.org.
    _ws._tcp.some-domain.org. IN SRV 1 40 80 ws2.some-domain.org.
    _ws._tcp.some-domain.org. IN SRV 2 0 8080 ws3.some-domain.org.

- The client would then choose between the two records with best
priority (1) taking into account their weight (60 and 40), so for
example ws1.some-domain.org:80.

- In case such destination is unreachable the client would take the
second one (ws2.some-domain.org:80).

- If also unreachable, then the third option (with less priority)
would be chosen (ws3.some-domain.org:8080).

NOTE: In case of WS over SSL/TLS, the SRV query would be
_wss._tcp.some-domain.org.

In this way, WS gets load balancing (based on SRV records weitgh) and
failover (based on SRV records priority). Of course, in case there is
not SRV record for _ws._tcp.some-domain.org, the client would then
perform a common DNS A query for some-domain.org as usual. So SRV
records are not mandatory (this is also true in SIP and XMPP).

IMHO, this is very useful and should be part of any new communication
protocol in Internet. But it should be defined as part of the
WebSocket specification from the beginning rather than being a future
addition (after WS is widely implemented it will be hard to introduce
it).

Best regards.

[*] DNS SRV: http://tools.ietf.org/html/rfc2782

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 28 Mar 2011 10:39:09 +1100

I agree it would be good to have websockets somehow support DNS loadbalancing.

However, I do know that we have been very concerned to reduce the
latency needed to establish a WS connection and I'd be concerned if
every normal WS connection would now be delayed by an extra DNS lookup
time.   I'd also not like to make it mandatory that clients have to
support it.

Would it be practicable to only support this if the client used
_ws._tcp.mydomain.org as the hostname in the WS connection?  If they
used www.mydomain.org, then normal DNS processing would take place?

cheers

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 01:53:52 +0200

2011/3/28 Greg Wilkins <[email-masked]>:
> time.

SIP clients (phones usually) use NAPTR and SRV queries. XMPP clients
use SRV queries.
Both are realtime protocols, so the minimal latency an extra DNS query
takes is negligible.

Also, such DNS SRV query is *just* performed once: before establishing
the connection with the WS server.

> I'd also not like to make it mandatory that clients have to
> support it.

It's possible to create a SRV and a A record for a domain. Clients not
implementing SRV could just query the A record.

> used www.mydomain.org, then normal DNS processing would take place?

No, that it's not the way DNS SRV works. The client would just see
"ws://mydomain.org/chat" in the JavaScript code got from the HTTP
server.

Since the WS URI doesn't not contain a port, then the client should
perform a DNS SRV query with this data:
- domain:  mydomain.org
- service: ws
- transport: tcp

Don't think that _ws._tcp.mydomain.org is a real domain (in fact the
symbol "_" is invalid in a domain). It's just a representation of the
query the client must perform:  _SERVICE._TRANSPORT.DOMAIN.

If the URI would include a port ("ws://mydomain.org:80/chat") then the
client should NOT perform a SRV query, but just a A query.

So, in case the URI has no port ("ws://mydomain.org/chat") the client
should perform a SRV query for domain "mydomain.org", service "ws" and
transport "tcp". If there is a SRV record for such query, then use it
(it would require an aditional DNS A query for the chosen record
entry). If there is no SRV record, then the client should perform a
normal A query for domain "mydomain.org" and assume default port 80.

As I said, SRV is widely used in SIP and XMPP, and it's very useful and easy.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 01:58:20 +0200

> I agree it would be good to have websockets somehow support DNS loadbalancing.

SRV is not just for load-balancing (with different weight per entry),
but also for failover/redundancy. This is, if the chosen entry is
unreachable, the client would use the next one.

This is important.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 28 Mar 2011 14:48:11 +0800

> new protocol and could take advantage of it.

I don't think this is necessary.  SRV exists to provide name-based discovery for a service (without a default port).  This is largely unnecessary for WebSockets.  In actuality, it's probably more likely to interfere.  I.e., which port do you use: the one in the URI, or the one that SRV told you to use.

--Martin

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 08:55:37 +0100

On Mon Mar 28 07:48:11 2011, Thomson, Martin wrote:
> I don't think this is necessary.  SRV exists to provide name-based  
> discovery for a service (without a default port).  This is largely  
> unnecessary for WebSockets.  In actuality, it's probably more  
> likely to interfere.  I.e., which port do you use: the one in the  
> URI, or the one that SRV told you to use.

I suggested the use of SRV myself some months ago.

Stream based services benefit hugely from SRV records, and these have  
been deployed in the field with much success within the XMPP world.

They are generally not used for port selection, but to allow the  
diversion of a service from one name (the domain) to another (the  
providing host). Use in WebSockets would allow a stock webserver to  
be used for static content whilst using a different specialist server  
(or servers) for WebSocket connections, which might prove very useful.

(To clarify: in XMPP, they're used heavily, and nearly always use the  
same port numbers.)

Specifying that if a port number is provided, then SRV lookup should  
not be performed, is I think sufficient to remove ambiguity.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 10:34:58 +0200

> I don't think this is necessary.  SRV exists to provide name-based discovery for a service (without a default port).  This is largely unnecessary for WebSockets.  In actuality, it's probably more l…

Hi Martin, I think you haven't read my mails in which I explain how
SRV works. I've clearly explained that, in case the URI contains a
domain:port then no SRV query must be done, but just A.

Also, I've explained that SRV is not just for "provide name-based
discovery for a service". SRV provides *Real* load-balancing and
failover. This doesn't exist in HTTP (in which just a hack is used: a
DNS A record with different IP's).

Please, reuse existing tecnologies. If you have more questions about
SRV please ask me and I will describe in in more detail, but please,
read first what I've already explained.

Regards,

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 10:41:04 +0200

2011/3/28 Dave Cridland <[email-masked]>:
> Stream based services benefit hugely from SRV records, and these have been
> deployed in the field with much success within the XMPP world.

Also in SIP world :)

> They are generally not used for port selection, but to allow the diversion
> of a service from one name (the domain) to another (the providing host). Use
> in WebSockets would allow a stock webserver to be used for static content
> whilst using a different specialist server (or servers) for WebSocket
> connections, which might prove very useful.
>
> (To clarify: in XMPP, they're used heavily, and nearly always use the same
> port numbers.)
>
> Specifying that if a port number is provided, then SRV lookup should not be
> performed, is I think sufficient to remove ambiguity.

Yes it is. The problem is that IMHO people too much involved in HTTP
doesn't know SRV as HTTP doesn't make usage of it. Also note that
WebSocket takes no advantages of other existing tecnlogies. At the
beginning it wasn't real HTTP, now it looks more like HTTP, but it
takes no advantage of other cool specifications, why?

Please guys, consider adding SRV to WebSocket, it's a great mechanism
for providing load-balancing and failover without dirty hacks. This is
the moment for it, and not later in an ugly feature addition nobody
will support.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 28 Mar 2011 18:36:32 +0800

On 2011-03-28 at 09:55:37, Dave Cridland wrote:
> providing host). 

Security on that front is a little iffy.  See draft-barnes-hard-problem.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 12:43:12 +0200

> Security on that front is a little iffy.  See draft-barnes-hard-problem.

Do you consider this "security issue" a real show-stopper for
supporting SRV records in WebSocket? Me not.

The provider could use subdomains of its root domain as A records into
its SRV record, so the problem doesn't arise.

I don't think the corner case described in draft-barnes-hard-problem
is so important. IMHO it's more important to provide load-balancing
and failover to a new protocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 28 Mar 2011 18:47:44 +0800

> supporting SRV records in WebSocket? Me not.

It wasn't intended as an argument along those lines.  I was merely hoping to illuminate the issue.
 
> its SRV record, so the problem doesn't arise.

I'm afraid that this doesn't work.  The nature of DNS delegations are such that subdomains cannot be guaranteed to belong to the same entity.

> and failover to a new protocol.

It's not a corner case.  It's the general case of having a secure delegation.  Delegation can be done really easily without any assurance of integrity, but if you want a secure delegation, that's not easy (it's HARD).

--Martin

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 11:57:03 +0100

> draft-barnes-hard-problem.

Actually it's straightforward from a technical standpoint, until you  
delegate services across administrative boundaries. Again, the XMPP  
world has been successfully authenticating using X.509 certificates  
with SRV records in play for many years.

Richard's been working closely with the XMPP community to find a  
solution to the "HARD" problem of cross-boundary delegation, but  
meanwhile I'd note that the problem exists with HTTP just as much as  
with XMPP and other SRV-using protocols, the primary distinction  
being that there is no explicit delegation visible, so people don't  
notice it as much. (Which is odd, since in HTTP there is a far  
*higher* delegation level for secure sites, as few as there are).

The actual problem only exists in the case where the private key  
cannot be given to the hosting organization, and I'd note is easier  
to solve if SRV records exist, thanks to DNSSEC (and the ability to  
then validate the delegation to an intermediate indentity one can use  
in the certificate).

So in summary, SRV records actually simplify the problem.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 13:49:18 +0100

> the connection with the WS server.

... for the first time. After that, it'll be cached like any other  
DNS query until the TTL expires, which can often reduce the latency  
to effectively zero.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 28 Mar 2011 09:57:52 -0700

Is there any reason that the interaction of Websockets and DNS SRV could 
not be handled in a separate draft? That is how it is done in the SIP 
world between RFC3261 and RFC3263.

Also, my interpretation of the SIP RFC is that it allows for DNS lookups 
that do not use DNS SRV (via a "local policy"). I'm not sure that using 
DNS SRV lookups should be a mandatory part of every websockets 
implementation. Recommended, sure, but not required.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 19:05:12 +0200

2011/3/28 Bruce Atherton <[email-masked]>:
> Is there any reason that the interaction of Websockets and DNS SRV could not
> be handled in a separate draft? That is how it is done in the SIP world
> between RFC3261 and RFC3263.

Both are two different RFC, true, but RFC 3261 references RFC 3263 for
resolving server location based on DNS SRV.

> that do not use DNS SRV (via a "local policy"). I'm not sure that using DNS
> SRV lookups should be a mandatory part of every websockets implementation.
> Recommended, sure, but not required.

The point here is that DNS SRV is not mandatory. For example:

- The JS in a web page must open a WS connection with ws://mydomain.org.

- Then the WS client performs a SRV query for domain=mydomain.org,
service=ws and transport=tcp.

- If such DNS SRV record exists, then the client chooses one of the
entries (based on weight and priority) and performs a DNS A query for
the domain of the chosen entry, and then connects to the resolver IP
and the port indicated in the chosen SRV entry.

- In case such DNS SRV doesn't exist, then the WS client should
perform a DNS A query for mydomain.org, and connect to the resolved IP
and default port (80 for ws:// and 443 for wss://).

Also, in case the ws URI does contain a port (i.e:
ws://mydomain.org:8080) then the WS client MUST not perform a SRV
query, but just a DNS A query for mydomaing.org and connect to the
resolved IP and port 8080 (as usual).

So the WS client should check for the existence of a SRV record for
the given domain (if no port is given), but the SRV record could exist
or not. It's very flexible but, of course, in order to work properly,
it should be mandatory for WS clients.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 28 Mar 2011 19:11:11 +0200

>it should be mandatory for WS clients.

It would seem very unlikely that all client implementations will do this
(because the feature is obscure to many, lack of test servers, lack of
proper DNS libraries that make this easy, not getting around to it, not
caring, and so on). As I understand it, not supporting SRV lookups is a
common problem with simpler XMPP implementations, for instance. So, if
this was mandatory for Websocket clients, we'd likely be looking at many
non-compliant implementations. Putting it the other way around, usually
people don't implement features just because they are formally required.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 18:20:09 +0100

> people don't implement features just because they are formally  

Your understanding is probably a little outdated.

While it's true that there exist some XMPP libraries and clients  
which cannot perform SRV lookups, these are very rare nowadays, and  
really restricted to simple utility scripts.

In the WebSocket world, there are very many fewer client  
implementations to worry about, which will also make it easier.

Dave.

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 28 Mar 2011 10:25:28 -0700

> resolving server location based on DNS SRV.

Sure, but because it was in a different draft the specifics of what it 
says has no impact on RFC3261. It could have talked about only using A 
records and RFC3261 could remain unchanged.

> The point here is that DNS SRV is not mandatory.

We are talking about two different kinds of "mandatory". You are saying 
that it is not mandatory for there to be DNS SRV records. I am saying it 
should not be mandatory for a Websockets client to look up DNS SRV 
records before looking up DNS A records. Not everyone will want or need 
the extra complexity.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 28 Mar 2011 19:30:16 +0200

> people don't implement features just because they are formally required.

A WS client could not support SRV and still work. Example:

- For domain mydomain.org there are a DNS SRV record and 3 DNS A records:

  SRV record:

     _ws._tcp.mydomain.org. IN SRV 1 0 80 mydomain.org.
     _ws._tcp.mydomain.org. IN SRV 2 0 8080 backup.mydomain.org.

  A records:

      mydomain.org.                 1.1.1.1
      backup.mydomain.org.      1.1.1.2

- The web page indicates the following WS URI:  ws://mydomain.org.

case 1) SRV capable WS client
-----------------------------------------------------------------------

- It performs a SRV query for domain=mydomain.org, service=ws and transport=tcp.

- It gets the SRV record with two entries and chooses the first one
(with best priority).

- So it performs a DNS A query for domain "mydomain.org" and gets 1.1.1.1.

- Then it connects to 1.1.1.1:80.

- In case the server is unreachable, the client tries the second
location by performing a DNS A query for backup.mydomain.org and gets
1.1.1.2, so it connects to 1.1.1.2:8080 (failover, oh yeah !!!).

case 2) Non-SRV capable WS client
-----------------------------------------------------------------------

- It performs a DNS A query for domain=mydomain.org and gets 1.1.1.1.

- Then it connects to 1.1.1.1:80.

- In case the server is unreachable the client cannot do failover due
to its limitation (it doesn't support SRV, sorry).

So, as you can see, it's not fully required that the client supports
SRV, but if it does, it can take COOL advantages from it.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 29 Mar 2011 07:39:46 +1100

> DNS A record with different IP's).

So the problem using SRV for ws is that ws starts with a HTTP connection,
which may be existing and may be used for other HTTP requests if the
handshake fails.

So there is not much we can do to tell clients that they should use
SRV when creating the HTTP connection.

So why doesn't HTTP use it?

cheers

---

From: Dave Cridland <[email-masked]>
Date: Mon, 28 Mar 2011 21:53:41 +0100

> which may be existing and may be used for other HTTP requests if the
Right. Adam's going to hate me, but this would be a perfect use-case  
for a redirect.

But in any case, we can say that this is a MUST NOT. I appreciate  
this is somewhat bending the rules of HTTP compatibility, but I think  
it's worthwhile for the benefits that SRV records give.

> So why doesn't HTTP use it?

HTTP doesn't use it primarily because it was a concept not familiar  
to the designers of HTTP when it was created, and by the time the  
idea was put forward it was too late to change, since people had  
deployed web services on their domain roots (ie, cridland.net as well  
as www.cridland.net), and therefore there was no utility in a  
fallback to A.

(SRV records themselves were first specified in RFC 2052, back in  
1996, but the mechanism is a generalization of MX records, of course.  
Of some note is that the arguments being raised against SRV records  
here are also all applicable to MX records, which have been deployed  
successfully since the early 90's, and probably before).

Dave.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 01:16:56 +0200

> So why doesn't HTTP use it?

Maybe just because SRV appeared later then HTTP.

Anyhow, is it not enough to say that widely implemented protocols as
SIP and XMPP make extensive usage of SRV records? Innovation is not
always carried over HTTP ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 10:06:00 +0200

>> > DNS A record with different IP's).

There are many ways to do load balancing -- DNS is just one.

> Right. Adam's going to hate me, but this would be a perfect use-case for a redirect.

Indeed.

> But in any case, we can say that this is a MUST NOT. I appreciate this is somewhat bending the rules of HTTP compatibility, but I think it's worthwhile for the benefits that SRV records give.

No, it isn't.  SRV has a benefit when there is one authority within
the domain and that authority has control over DNS.  Historically,
that has not been the case for HTTP.  Web servers are not like email,
xmpp, or sip.  They are very direct and anti-establishment.

Is websockets? I don't know. I would find it strange to require
both the same-origin model and SRV, but I guess WS won't be using
same-origin requirements.

> HTTP doesn't use it primarily because it was a concept not familiar to the designers of HTTP when it was created, and by the time the idea was put forward it was too late to change, since people had deployed web services on their domain roots (ie, cridland.net as well as www.cridland.net), and therefore there was no utility in a fallback to A.

SRV was developed after HTTP and did not see any real deployment
until well after 2616 was done.  In any case, it would not have been
used by HTTP because a goal of web interaction is to have all of the
instruction provided to the client up-front in order to minimize latency.
DNS load balancing is only minimally effective because the client has
no choice but to make an initial DNS request (to be cached for the
remainder of its uptime).

> (SRV records themselves were first specified in RFC 2052, back in 1996, but the mechanism is a generalization of MX records, of course. Of some note is that the arguments being raised against SRV records here are also all applicable to MX records, which have been deployed successfully since the early 90's, and probably before).

Exactly, but email management is inherently centralized because of
the authentication.  Likewise for XMPP and SIP.  And none of those
are sensitive to per-interaction latency during the authentication phase.

Any service that relies on some form of centralized administration
is a good match with SRV if and only if the service lookup is faster
than the application requirements for user-perceived latency. The long
tail of HTTP sites is not of that type.  Only a very few websites
would gain any advantage from SRV, and those sites are already using
CDNs and IP-based load balancing to do the same thing without any need
for SRV.

....Roy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 10:39:53 +0200

> There are many ways to do load balancing -- DNS is just one.

So cheeaper as DNS SRV? based on a standard as DNS SRV?

>> Right. Adam's going to hate me, but this would be a perfect use-case for a redirect.

Does a 3XX redirect provide failover? No, it can provide just load-balancing.

> the domain and that authority has control over DNS.

Sorry, but in most of the web deployments the author of the web site
also owns the domain so he is free to configure SRV records if he
wants. I can't see the problem.

>  Historically,

If HTTP requires a new TCP connection for each request (or the exotic
and limited pipelined-mode of HTTP/1.1) then this is a limitation in
HTTP protocol (the same doesn't occur in other protocol better
designed as SIP-TCP or XMPP). Anyhow, the client must not perform a
SRV query for each connection, but just one at the beginning (to
resolve the domain).

But WebSocket is a new protocol, is not? In fact, the client
establishes an unique TCP connection with the WS socket, just one.

> instruction provided to the client up-front in order to minimize latency.

Again, the SRV query would be performed just *once*. That cannot
introcude noticeable latency.

> remainder of its uptime).

And what is the problem? why do you say "is only minimally effective"?
The client performs the SRV query at the beginning and internally
stores the result set. If a connection fails it then uses the next
rcached result to try the connection.

> are sensitive to per-interaction latency during the authentication phase.

SIP is not sensitive to per-interaction latency?

> CDNs and IP-based load balancing to do the same thing without any need

As I've explained and detailed various times in this thread, the web
adminitrator could decide to use *OR NOT* DNS SRV records for the
ws:// uri. He could still set an IP (ws://1.2.3.4:80) so the client
shouldn't perform a SRV query. Or he could set a domain with no SRV
record (but just A).

So, what is the problem? SRV would be a perfect choice for many people
but you want to prohibit it just because it would be not so useful for
other people (even if they can just ignore and not use it in their
deployments). It would be fully optional from the admin and user
perspective. The website owner could decide to use SRV or not. The
only requeriment, of course, os that WS clients support it (and WS
clients are built in the web browsers, so that shoud not be a
problem).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Patrick McManus <[email-masked]>
Date: Tue, 29 Mar 2011 11:20:56 +0200

> establishes an unique TCP connection with the WS socket, just one.
Websockets is a new protocol that bootstraps itself off of an HTTP 
transaction. Websockets does not define opening of TCP connections - 
that is HTTP's business. In fact, performing the upgrade of http->ws can 
be done off an idle persistent connection which saves a RTT. Indeed, it 
is very likely if the ws://host is the same as the base page holding the 
javascript that such an optimization will be available. That's a good thing.

If we would like to ignore HTTP and define different semantics for these 
things, then that is fine but ONLY if we want to give up the use of the 
one true port. I don't think that's worth it and it would be a complete 
reboot of the group.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Mar 2011 11:22:30 +0200

> So cheeaper as DNS SRV? based on a standard as DNS SRV?

Yes, both cheaper (no added latency) and based on standards (TCP/IP).

> Does a 3XX redirect provide failover? No, it can provide just load-balancing.

It is just an identifier -- it provides whatever is identified.

> wants. I can't see the problem.

That is just factually wrong, so there is no point in discussing it.

> SRV query for each connection, but just one at the beginning (to

Er, no.  They are very direct as in anyone can mint an identifier and
install their own web server, even if they don't know the domain owner.
They just need to be able to run a process on the host.  That is a good
thing, and it would be foolish to assume otherwise.

> establishes an unique TCP connection with the WS socket, just one.

Yes, it has nothing to do with why SRV is not used by HTTP.  I was
just answering that question, not stating a requirement for websockets.

> introcude noticeable latency.

I suggest you open a protocol analyzer and see for yourself.  Keep in
mind that the browser is not going to have SRV records stored from its
prior query on DNS, so it will have to do a new one.

> And what is the problem? why do you say "is only minimally effective"?

Because it is the truth.  DNS round robin or CDN-style geographic
rotation is only minimally effective at load-balancing because the
client stores the result for a long time.  IP-based redirecting is
a far more effective solution for load balancing.  In practice,
both are used for very high volume sites.

> rcached result to try the connection.

Failover and load balancing are not the same things, and DNS A
records come in result sets too.

> SIP is not sensitive to per-interaction latency?

Not in the same order of magnitude as HTTP.

> clients are built in the web browsers, so that shoud not be a

I did not say anything about prohibiting SRV with websocket.
I answered some bad assumptions about its lack of use with HTTP,
because I do know those answers.

....Roy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 11:46:30 +0200

> It is just an identifier -- it provides whatever is identified.

If the server having to reply the 3XX is down then it provides *nothing*.

> thing, and it would be foolish to assume otherwise.

I've already explained that including SRV records for a WS connection
would be fully optional. If the admin doesn't control the domain (just
has a A record available) it just ignores SRV in his application and
provides a WS URI with an IP or domain (wich just DNS A record).

> Keep in
> prior query on DNS,

Why not? perhaps you are describing the behavior of *current* web
browsers? should a future protocol (websocket) be limited by current
technology? If websockets mandates the usage of SRV, browsers
implementing it will improve their efficience by caching DNS results
and so.

> Failover and load balancing are not the same things,

Thanks, I do know it. Perhaps you could point where I've missed both
concepts (sure I didn't).

When a client receives the SRV record (containing various entries) it
must choose a entry with better priority.

In case there are more than one entries with same priority then it
chooses one of them based on their weight value (randomly). This, and
ONLY this, is load-balancing.

If the chosen connection fails, the client must choose the next one
(which could have same priority or less priority depending on the
entries). This is failover/redundancy.

SRV provides all of this in an easy way.

> and DNS A records come in result sets too.

And that is a hack as just provides load balancing (a client receiving
N IP's for a domain doesn't try the second one in case the chosen IP
fails to connect). Are you really comparing the DNS A with various
records (which is a hack) with the SRV mechanism (a standarized and
good designed load-balancing/failover mechanism)?

> because I do know those answers.

Ok, honestly I don't care the reasons HTTP doesn't use SRV. I'm just
trying to suggest its usage in WebSocket protocol. For now I've heard
no good reasons for disallowing it, just some bad assumptions about
SRV (due the lack of knowledge).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Mar 2011 03:31:29 -0700

Hi Inaki,
>SRV (due the lack of knowledge).

There were 18 messages posted to this mailing list about this topic 
yesterday.  This working group has a history of long discussions and 
abnormal levels of controversy.  To avoid all that, you could do the following:

  (i)   Propose some text to be inserted in the draft and accompany it
        with arguments for the change; or

  (ii)  Post an I-D as an individual submission; or

  (iii) Raise it as a issue during the WG session that will be held in
        30 minutes.

Regards,
S. Moonesamy
Hybi WG Secretary

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 29 Mar 2011 12:50:58 +0200

>  (iii) Raise it as a issue during the WG session that will be held in

Thanks, I'm already logged into the meeting as user ibc708 (just
available for chat).

-- 
Iñaki Baz Castillo
<[email-masked]>