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(_at_)google(_dot_)com>:
> >> ~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(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf