[150698] in North American Network Operators' Group
Re: Riverbed/Akamai/Rakamai
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Mar 1 10:55:21 2012
Date: Thu, 1 Mar 2012 07:54:12 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <CAKDfjgdmhYOjjcuEDhJkpgRpTrUdsGhdpRcDn0H0=J-hoc-8hw@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Thu, Mar 01, 2012 at 10:09:27AM -0500, Kristian Kie=
lhofner wrote:
> Does anyone know what they actually "do" and how they do it? As usual
> it's tough to cut through the marketing on the little detail they make
> available (never a good sign).
It's been a while since I looked at Riverbed, and it was part of a
test with other providers of the same technologies. So I'll give
you a general overview of the sorts of things they do.
"WAN Optimizers" implment an array of tricks to get more throughput
out of the same bandwidth:
- Compression, simply compress the data as it flows.
- TCP optimization, work around known issues with window scaling and
other TCP throughput problems by being a man in the the middle and
faking out one or both sides.
- Tricking LAN protocols into working over the WAN. This was one of=20
the first big selling points. Various MS LAN protocls weren't
designed for high latency links with packet loss, and so by being
a man in the middle dealing with the WAN and presenting an optimized
view they worked much better.
- Data deduplication, cache blocks of data repeatedly sent (file
sharing read-only documents is a prime example) at the far end
and re-serve them without going across a WAN.
- Caching various "soft failures" (PMTU failures, unreachables, etc)
to deliver them faster.
Depending on your workload they may be total magic, getting gigabits
of throughput from a T1, or snake oil, not making a bit of difference.
The key in all cases is they have to be paired though, one on each
end of the WAN (read low bandwidth and/or high latency) link. To
date that has limited them to deployments inside of enterprises for
the most part, and often to places with a hub and spoke topology
otherwise the deployment gets complex quickly.
What I'm hearing here is one of these "boxes" is in the Akamai node.
Now if the enterprise customer has one at their site you have two
end points for downloading Akamaized content. This may be able to
optimize throughput (say, via compression or TCP optimization) or
reduce load/costs (say via data deduplication) or both for a customer
who happens to have a Riverbed box on their network.
I've got no idea how effective this would be on standard Akamized
content, but if you already own a Riverbed it's probably some "free"
optimization. Is it enough to make you buy a Riverbed if you don't
already own one? Interesting question.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBT0+bo7N3O8aJIdTMAQJd/hAAt7x3/MQX6a4h+9qLBl/GaHnlhrx7LJMq
GDdOz+8lwnkknTmMoExhI84TqfsdHOgFIYqGAW5LkCC0CIH1HSC+rYZxNLgKQFJ4
LpC5JeZfD0HfkMZ2BEpyBMhYGMxLo+e+VpOVDmI44VsxNrNjnXUJzNtDi9U/jGOT
M9pfDRvt6pDOVFeUvUwlYSV6UNWYZyyiKHbXjXouhB4EbzZfNZoUrLwkzyIxrixP
j5785JBLNvuWOYXFwfiIWtsNSULLxNl9buq0OIeuq0lfZSV7kVIpx1Ia2ggy/Xie
Qs3yjrO7sFiIbc9f0iUq0w7G0I6ngg1Jnx8b52JCBK+YnPEf8Ttnsb5+SPAXqzsQ
7dzqc9+23/Rz/rc3FEy8eTo0ZtOJasWa5rLJjjqVFtqgpB2FEtYe/rI+DuZX/zr0
6HAsek4vYNqwKl+izEGPeYf15kEd2Qb6WnZ24fdpdqnSrq95CM5APCnVuMG9yeWY
QWeLjhTbUNq2BYYj+7AeS/9sTVBNTjXnJW6tRxd34rGv57IvCFsgX3ifWqDFJSJV
yjQ+ZlrUSJO9IjARS0+tW/InzMsn0Jn0zVXljcoO1BUILLfxE2IzHecKRrCMz8di
rbPaFWL3VLsa2tLB5Tp8LKUYWQwd9S0s9FYliZP6mudEIqxVoT+bB5axyPLv3UB7
W2uddTlFxC0=
=hySn
-----END PGP SIGNATURE-----
--TB36FDmn/VVEgNH/--
