ietf
[Top] [All Lists]

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

2011-07-27 11:01:53
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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>