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

David Conrad <drc@virtualized.org> Mon, 25 July 2011 01:49 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5250021F8538 for <ietf@ietfa.amsl.com>; Sun, 24 Jul 2011 18:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 yzTM9okT6fss for <ietf@ietfa.amsl.com>; Sun, 24 Jul 2011 18:49:36 -0700 (PDT)
Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by ietfa.amsl.com (Postfix) with ESMTP id C251021F8532 for <ietf@ietf.org>; Sun, 24 Jul 2011 18:49:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 5DB8814C632D; Sun, 24 Jul 2011 18:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at virtualized.org
Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U98267eFluuP; Sun, 24 Jul 2011 18:49:34 -0700 (PDT)
Received: from [10.0.1.10] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) by virtualized.org (Postfix) with ESMTP id 58E3E14C6322; Sun, 24 Jul 2011 18:49:34 -0700 (PDT)
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="iso-8859-1"
From: David Conrad <drc@virtualized.org>
In-Reply-To: <20110724191641.GC22405@1wt.eu>
Date: Sun, 24 Jul 2011 15:49:33 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <644A437E-BB0D-45E9-B6C3-5EF66A811986@virtualized.org>
References: <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <CALiegf=pYzybvc7WB2QfPg6FKrhLxgzHuP-DpuuMfZYJV6Z7FQ@mail.gmail.com> <B2C17B21-EA8A-4698-8C41-F55A9AA140D4@gbiv.com> <CALiegfkshhJVUHzTD1Kka5+RjGwZ5CS2J=Qk92jfSBg6Z0VfOQ@mail.gmail.com> <C9CD680E-8D68-4380-A76F-70F41F30F877@gbiv.com> <CALiegfkFnKjP09Vijo3c_DFYn4=UZm9M-4mVuZUyBk8rzwmDCw@mail.gmail.com> <20110724191641.GC22405@1wt.eu>
To: Willy Tarreau <w@1wt.eu>
X-Mailer: Apple Mail (2.1244.3)
Cc: IETF-Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 01:49:37 -0000

[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.

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.

> None is cheaper nor better than the other.

CNAME results in the resolver doing additional work, generally resulting in no need for an additional query but is not applicable in all situations (e.g., putting a CNAME at a zone apex is a gamble). SRV is far more general solution with additional benefits (e.g., priority) but requires an additional query.  The two RR type solve different problems.  CNAME is an alias for a host.  SRV provides information about services at a host.

On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote:
> DNS provides geolocation and proposes you the closest working datacenter.

No it doesn't.  The DNS _may_ provide a reasonable facsimile to geolocation if and only if the resolver is co-located with the requester. In a world of Google DNS, OpenDNS, ISP-wide anycast resolvers, etc., the assumption that the location associated with the IP of a DNS query correlates to the IP address of the HTTP initiator becomes increasingly dangerous.

>> 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'.  This is qualitatively different than the prioritization offered by SRV.

Regards,
-drc