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

Dave Cridland <> Sun, 24 July 2011 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A7C521F8749; Sun, 24 Jul 2011 13:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5Bn3xI1-uQ8; Sun, 24 Jul 2011 13:18:47 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by (Postfix) with ESMTP id 0C49621F8747; Sun, 24 Jul 2011 13:18:47 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTP id A20FF1168087; Sun, 24 Jul 2011 21:18:44 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bre1gkv-YN4w; Sun, 24 Jul 2011 21:18:40 +0100 (BST)
Received: from puncture ( [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by (Postfix) with ESMTPA id 6785E1168067; Sun, 24 Jul 2011 21:18:40 +0100 (BST)
References: <9031.1311270000.588511@puncture> <> <> <> <9031.1311286867.939466@puncture> <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <9031.1311538720.416128@puncture>
Date: Sun, 24 Jul 2011 21:18:40 +0100
From: Dave Cridland <>
To: Willy Tarreau <>, Server-Initiated HTTP <>, IETF-Discussion <>, =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jul 2011 20:18:48 -0000

On Sun Jul 24 19:59:49 2011, Willy Tarreau wrote:
> On Sun, Jul 24, 2011 at 08:30:11PM +0200, Iñaki Baz Castillo wrote:
> > 2011/7/24 John Tamplin <>om>:
> > >> ~100 ms (if the DNS server is not local and there is no DNS  
> cache for
> > >> the given domain). And just during the WS connection, no more.  
> Taking
> > >> into account that a WS will be *usually* connected after  
> loading a web
> > >> page, such ~100ms in a non-full-realtime protocol is  
> insignificant.
> > >
> > > Wait, are you really saying that 100ms connect latency is  
> unimportant?
> >
> > Open the fastest web page and tell me how long it takes. Probably  
> you
> > have performed a DNS A query. I don't think that a xtra DNS query
> > would be the bottleneck, never.
> On lossy networks such as 3G, they definitely are. A lost UDP  
> packet is
> not retransmitted nor signaled as lost, so the browser has to  
> retry. However,
> once the connection is established to the server, most losses are  
> more or
> less smoothed by TCP extensions such as SACK. So yes, it can take  
> several
> seconds to just resolve a host and then only a few hundreds of ms  
> to retrieve
> the objects. I've observed it.

I think what might be colouring your opinion regarding DNS resolution  
times on mobile is the difference between the first and subsequent  

3G sessions, in a reasonable area, drop to around 100-150ms, although  
they can go up to 300ms or higher if the network condition  
deteriorates. However, the setup of DCH, the radio state normally  
used for internet traffic (and needed for DNS requests and  
responses), takes a healthy number of round-trips, so that the first  
RTT is about three times longer.

Moreover, it's not clear to me that SRV lookup always (or even  
commonly) adds an additional round-trip. Take an XMPP client SRV  
lookup to my own server:

$ dig SRV

;; ANSWER SECTION: 86400 IN SRV 5 2 5222


86400	IN	AAAA	2001:470:1f09:882:2e0:81ff:fe29:d16a

Note that the addresses of the actual server are returned in the  
additional section. My understanding is that in practical terms  
this'd always happen for in-zone cases. (If there's a large number,  
you may not get them all, since they can be discarded without error,  
but it practise you're likely to).

Finally, as I've said before, I think that any overhead involved is  
going to be swallowed up in the noise of general session startup in  
the WebSocket case. I do appreciate things are at the very least  
perceived as different in the HTTP case, although I think SRV would  
help solve issues (like off-site failover) there, too, but I think  
the moment you have long-running stateful sessions, you'll end up  
with the same impact to user experience of a few extra RTTs at  
startup as is seen in XMPP, SIP, and so on - that is, none.

100ms extra on a 100ms request/response would be bad, I agree, but  
that's not what we're talking about.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade