Peering with a big web farm (was Re: BBN Peering Issues)
Sean M. Doran
smd at clock.org
Wed Aug 12 20:27:20 UTC 1998
Forgive me, but this raises an interesting engineering
and traffic-management issue.
Alex Rubenstein, turning John Curran's words around, suggested:
| "The central problem is asymmetry of traffic between GTEI and the hosting
| companies, Curran said. BBN/GTEI customers generally request webpages from
| Exodus more than from other places."
which is an interesting point IN FAVOUR OF peering with a large
web hosting network at only one location.
If one can force all outgoing to-the-webhosted-site queries
through a single web cache, and the content is (or is made to be)
relatively undynamic, one has a huge caching potential.
With hot-potato routing towards a multiply-connected network,
the egress funnel which allows one to intercept all queries
The "firehose" of replies back is mitigated not by a large
cache on the "large-audience" side of the peering, but by
clever distributed caching combined with redirecting browsers
from the "egress funnel intercpetor" to caches which are
closer to them.
Ideally one would only ever need one transfer per new piece
of content to satisfy one's entire customer base. Moreover,
depending on how static one required the content to be
(or conversely, how dynamic one allowed it to be), the actual
peering connection might even be intermittent.
How one would contract for this sort of peering, of course,
is a matter for com-priv, not for NANOG.
More information about the NANOG