ietf
[Top] [All Lists]

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

2011-07-25 19:25:29

In message <20110725045821(_dot_)GN22405(_at_)1wt(_dot_)eu>, Willy Tarreau 
writes:
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.

You are missing the point.   The following is illegal though some nameservers
allow you to load the zone.

        example.com SOA ...
        example.com CNAME ...

This is not illegal

        example.com SOA
_http._tcp.example.com SRV ...

Nor is a fictional HTTP record which adds the same level of
indirection as CNAME.
 
        example.com SOA ...
        example.com HTTP <server>

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 ser
ver 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.

But it adds a lot of value to everyone else using the DNS.  By HTTP
clients and adminitrators abusing CNAME to achieve what SRV achieves
cleanly they cause problems elsewhere.

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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

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