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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jat@xxxxxxxxxx>:
> >> ~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 RTTs.

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 _xmpp-client._tcp.dave.cridland.net SRV
;; QUESTION SECTION:
;_xmpp-client._tcp.dave.cridland.net. IN	SRV

;; ANSWER SECTION:
_xmpp-client._tcp.dave.cridland.net. 86400 IN SRV 5 2 5222 peirce.dave.cridland.net.

;; AUTHORITY SECTION:
dave.cridland.net.	86400	IN	NS	br.cridland.net.

;; ADDITIONAL SECTION:
peirce.dave.cridland.net. 86400	IN	A	217.155.137.61
peirce.dave.cridland.net. 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.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]