
Jeff Dean - Achieving Rapid Response Times in Large Online Services - tim_sw
http://research.google.com/people/jeff/latency.html
======
colmmacc
Jeff Dean's presentation comes close to suggesting concurrency as an approach,
with the 2ms wait-and-see approach, but I often wonder if a truly concurrent
pattern of access is feasible in some cases.

For many idempotent operations, it seems likely the most fault-tolerant and
latency-optimizing pattern is to ask multiple endpoints concurrently - take
the first to respond, and discard or terminate the duplicates (and if one
fails, so what?). Obviously this isn't cheap; sufficient bus/network and
endpoint capacity is necessary - but isn't it the natural progression of a
trend?

Some RAID1(0) implementations behave like this (for reads) already.

In say 5 years, might it be optimal for web browsers to initiate TCP
connections to multiple web endpoints, and go with the first to initialise?
One would imagine the additional TCP load to be tolerable. Or maybe even
multiple full HTTP requests and take the first to fully succeed - maybe bits
will be cheap enough to transmit by then that the gains are worth it.

In say 20 years, might it be optimal for networks to disperse packets via
multiple diverse paths, and ignore duplicates? Just how cheap can Moore's law
and Shannon's theorem push network transmission?

DNS requests are so cheap that many DNS resolvers already implement this
technique - sending queries to authoritative servers in parallell and just
going with the first to respond.

Clearly there are many times when concurrency is worse; non-idempotent
operations, or when read-after-write consistency is required. And of course
the costs have to be manageable and make sense. But I'd love to know of any
economic or technical studies that have been made for the approach in general.

~~~
modeless
_In say 5 years, might it be optimal for web browsers to initiate TCP
connections to multiple web endpoints, and go with the first to initialise?_

In fact, browsers do something like this today to deal with broken IPv6
implementations, under the name "Happy Eyeballs":
[http://tools.ietf.org/html/draft-ietf-v6ops-happy-
eyeballs-0...](http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-05)

The idea is that if a IPv6 connection isn't established after 300ms then the
browser just starts a duplicate connection over IPv4 and uses whichever one
comes back sooner.

~~~
colmmacc
That's another good example! But 300 ms is nearly four times the limit of
human perception. So I do wonder if - as network and service costs diminish -
simply using many connections for the same thing won't seem so "wasteful".

------
bbgm
There is a lot of good stuff on Luiz Barroso's page as well:
<http://research.google.com/pubs/LuizBarroso.html>

------
sanxiyn
See also a previous discussion: <http://news.ycombinator.com/item?id=3694148>

