Peering with a big web farm (was Re: BBN Peering Issues)
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 disappears. 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. Sean.
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.
Amen; I didn't even see that. But, that could work to BBN's favor! -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
On Wed, 12 Aug 1998 alex@nac.net wrote:
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.
Amen; I didn't even see that. But, that could work to BBN's favor!
If BBN wants to sell connectivity to a big web farm provider, how does BBN's forcing all hits through a cache help BBN? The data all still crosses BBN's backbone, and the the web farm provider won't need as big a pipe. Maybe I'm missing something, but if BBN starts charging former peers, I'd think caching at these edges would be a bad thing for BBN. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Hmm, In that case, doesn't it become an advantage for the webfarm who is now buying transit to put up the cache ? -dave
On Wed, 12 Aug 1998 alex@nac.net wrote:
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.
Amen; I didn't even see that. But, that could work to BBN's favor!
If BBN wants to sell connectivity to a big web farm provider, how does BBN's forcing all hits through a cache help BBN? The data all still crosses BBN's backbone, and the the web farm provider won't need as big a pipe. Maybe I'm missing something, but if BBN starts charging former peers, I'd think caching at these edges would be a bad thing for BBN.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Thu, 13 Aug 1998, David Schiffrin wrote:
Hmm, In that case, doesn't it become an advantage for the webfarm who is now buying transit to put up the cache ?
-dave
Yes, it does. The problem here is that current caches aren't designed for content speed, and response. But with caches at the content end, it saves cross-country bandwidth for the content provider, but really doesn't help the dial-up farms. Mike Gibbs
On Wed, 12 Aug 1998 alex@nac.net wrote:
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.
Amen; I didn't even see that. But, that could work to BBN's favor!
If BBN wants to sell connectivity to a big web farm provider, how does BBN's forcing all hits through a cache help BBN? The data all still crosses BBN's backbone, and the the web farm provider won't need as big a pipe. Maybe I'm missing something, but if BBN starts charging former peers, I'd think caching at these edges would be a bad thing for BBN.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
participants (5)
-
alex＠nac.net -
David Schiffrin -
Jon Lewis -
Mike Gibbs -
Sean M. Doran