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

[Willy Tarreau <[e-mail]>]

On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote:
> [I haven't been following hybi and haven't read the draft, but as this is posted to the ietf list and there are a bunch of assertions here about the DNS I consider ... odd, I thought I'd chime in]
> 
> On Jul 24, 2011, at 8:59 AM, Willy Tarreau wrote:
> > A lost UDP packet is not retransmitted nor signaled as lost, so the browser has to retry.
> 
> This sounds like a seriously broken resolver.  All resolvers I'm aware of have timeouts and retry if no response is received within the timeout. A resolver that gives up after a first time out is equivalent to a TCP stack that doesn't retransmit a SYN.  A bug should be filed with the vendor.

What are you saying ? Your browser embeds the resolved as a library, so when
I'm saying that "the browser has to retry", I mean the resolver part of the
browser has to retry.

> On Jul 24, 2011, at 9:16 AM, Willy Tarreau wrote:
> > CNAME is the exact equivalent of SRV.
> 
> No. According to the RFCs and most implementations, you can't have CNAME with other data (A, MX, SOA, NS, etc).  With SRV, you can have anything at the same label.

This does not change anything, because the CNAME is on the hostname while
the SRV is on the service name, so there is nothing wrong with having both.

> On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote:
> > DNS provides geolocation and proposes you the closest working datacenter.
> 
> >> Anyhow, don't forget that SRV is not just for failover, but also for load-balancing
> 
> > This is already addressed by DNS round robin and used by a lot of sites.
> 
> Only at the grossest level. What a client get back from a query depends on who has queried the same cache and authoritative server and what policy the authoritative server has for returning answers.  In reality, 'round robin' is 'random'.

Yes but in practice, this randomness offers very smooth distribution.

>  This is qualitatively different than the prioritization offered by SRV.

Indeed this is different, but this does not mean there is a huge need for
the minor improvements provided by SRV in this context.

I'm not saying that SRV is useless but that it adds little value to HTTP
and even smaller to WS without HTTP, and comes at a non-zero cost, whatever
people are saying. I'm also certain that if a new record were to be invented
(eg: report the server's load in real time), there would be major proponents
to make it mandatory for everything because it would be what would save the
world from an upcoming disaster.

I'm convinced we can find good use cases for SRV combined with either HTTP
or WS once we admit it is optional and the user controls this option. Try
to imagine what you could do if you knew that 50% of your visitors would
consider your SRV records. Maybe you could use them to progressively test
service updates. You could possibly get a better distribution, or serve
a maintenance page to some of them during maintenance operations instead
of leaving them in the dark. You have to think what the benefit can be
for the user to enable the option, not how to push it down his throat.

Regards,
Willy