- Test - lists.nanog.org

Re: Worldly Thoughts - Regionalizing Peering
by John Curran 13 May '96

13 May '96

At 8:24 PM 5/11/96, Alan Hannan wrote: > The model scales well, imho. Regionalize your network into > pieces. Apply each of the pieces into 1 or more proximities to a > NAP|MAE. Been there, done that.... I've already stated my view on the scalability of such arrangements. > Benefit: I gain low latency transit to most everyone. > > Drawback: It is technically challenging to create an automate > system to regionalize and create appropriate filter lists. It also complicates every peering relationship and multi-homed customer connection, as you have to worry about both multiple external AS's and your internal routing redistribution from all of these regional routing clouds. If you presume a fairly dense set of interconnects among transit providers, then you're not going to get a significant improvement in latency despite the added complexity. /John

2 1

Re: topological "closeness" (RE: Web o' Wonder)
by Mike Trest 13 May '96

13 May '96

>On Mon, 13 May 1996, Mike Trest wrote: >> I am implementing a CACHE simply to improve on-net customer satisfaction. I >> expect the operational costs to be much less than the equivilent backbone or >> transit costs. If it has a side effect of reducting meet point traffic, then >> the entire net benefits. > >Doesn't this require reconfiguring the customer's browsers to point at a >proxy? Yes. Initial customer reaction is, at first, hesitant. However, when they try it an see *DRAMTIC* improvements in response times. This is predicated on the "closeness" of the cache relative to dragging the stuff over the whole world. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1901 San Diego, CA 92121 Pager: 619 960-9070

2 1

Re: topological "closeness" (RE: Web o' Wonder)
by matthew＠scruz.net 13 May '96

13 May '96

Original message <2.2.32.19960513194819.00692964(a)pop3.atmnet.net> From: Mike Trest <trest(a)atmnet.net> Date: May 13, 12:48 Subject: Re: topological "closeness" (RE: Web o' Wonder) > > >On Mon, 13 May 1996, Mike Trest wrote: > >> I am implementing a CACHE simply to improve on-net customer satisfaction. I > >> expect the operational costs to be much less than the equivilent backbone or > >> transit costs. If it has a side effect of reducting meet point traffic, then > >> the entire net benefits. > > > >Doesn't this require reconfiguring the customer's browsers to point at a > >proxy? > > Yes. Initial customer reaction is, at first, hesitant. However, when they > try it an see *DRAMTIC* improvements in response times. This is predicated > on the "closeness" of the cache relative to dragging the stuff over the > whole world. > > Mike Trest, ATMNET Voice: 619 643-1805 > 5440 Morehouse Drive Fax: 619 643-1901 > San Diego, CA 92121 Pager: 619 960-9070 > >-- End of excerpt from Mike Trest Installing a cache proxy also means adding yet another thing to the list of "I wish I wasn't running one of these because some day I'll be in court over this". I'm already unhappy that there isn't adequate legal protection for me if/when I run a news server, and you're suggesting that I start keeping local disk copies of all the {illegal, copyrighted, trade secrets} information that's on the Web, TOO? When your site gets raided by the Secret Service and they grab your cache disks and take them home and run keyword searches on them, you're screwed. As soon as some nice legislation gets passed to protect me, the ISP, when I run a cache, I'll put one in and help solve the bandwidth problem. Saying "the network will break without cache servers" isn't a valid defense to charges of posession of illegal and/or copyrighted material. -matthew kaufman matthew(a)scruz.net ps. Yes, if for some reason I ever get some time off of running an ISP myself, I'm very likely to spend a lot of my time helping to make sure that the legal situation for people like ISPs improves significantly.

1 0

topological "closeness" (RE: Web o' Wonder)
by Mike Trest 13 May '96

13 May '96

Michael Dillon's Web o' Wonder scenario keys on the ability of smart servers to do an application level re-direction of load to a topographically more appropriate server. Some of our customer's sites are doing a fair job of this by weighting DNS responses to geographically dispersed sites which, hopefully, are topographically dispersed. >Seems to me that this scenario would also benefit from a tool and database >that could determine topological "closeness" even if it doesn't need to >generate filter lists. >If this scenario were easier to implement it could reduce the load of the >major exchange points by encouraging traffic to stay closer to the network >periphery. The CACHE research efforts (see: http://www.nlanr.net and others) indicates that even greater reductions would be obtained if NSP/ISPs increase use of caches for www. Individual campus statistics, the NLANR prototypes, and statistics from CACHE sites deployed internationally suggest that orders-of-magnitude reductions in external network access [i.e. our backbone load] could be achieved. I am implementing a CACHE simply to improve on-net customer satisfaction. I expect the operational costs to be much less than the equivilent backbone or transit costs. If it has a side effect of reducting meet point traffic, then the entire net benefits. I wonder, how many nets would implement such as cache if the effect would be to reduce meet point traffic by orders-of-magnitude? ..mike.. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1901 San Diego, CA 92121 Pager: 619 960-9070

2 1

Re: topological closeness....
by avg＠postman.ncube.com 13 May '96

13 May '96

Should i drop into Noel-speak mode and start explaining difference between O(n) and O(exp(n))? If something works in several dozens or several hundreds places does not mean it'll work in million places. And even if it can work in million places but can't work with two million places it is only half year worth of growth. --vadim

1 0

Re: topological closeness....
by avg＠postman.ncube.com 13 May '96

13 May '96

>If I could _enforce_ caching by traffic interception then >I could construct vaguely logical cache structures as an ISP. One way to do that is to spoof TCP sessions in the routers :) That is a horrible kludge, though... >But relying on users to configure their end systems with the >identity of the closest cache server using some ill defined >"network metric" is always going to be an erratic affair at best. How about allocating fixed IP address for cacheing servers? Routing will take care of locating the "closest" one, and browser vendors would be able to hardwire the default address. Although one can tell that they have little clue and probably won't do anything about it, given such impressive items on their track record as HTTP 1.0 or Netscape HTML extensions. --vadim

1 0

Re: Worldly Thoughts
by Dave Curado 12 May '96

12 May '96

> ] > Or, possible some small providers buy a multi-megabit circuit from a > ] > large provider who gives them transit. The small provider then connects > ] > at a single NAP and picks up bilateral peering sessions with a bunch > ] > of people there. The result is offloading traffic from their > ] > "transit link", which stands a good chance of being priced as a > ] > "burstable" link. (pay for what you use) That gives the small > ] > provider an economic incentive to operate in this manner. > > ] Quite a few CIX members operate this way. The interesting question in my > ] mind is whether the "big guys" (defaultless nets, for the purposes of this > ] discussion) think that this represents unfair competition or not. > > We've a defaultless net, but I'm not sure that I'm considered a > 'Big Guy'. Hell, we only route 1% of the internet, but maybe if I > lost my aggregates I could be bigger ;) > > The hidden metric that davec above doesn't consider is latency. > > If I peer at a NAP, I forgo the latency my upstream 'multi-megabit > circuit' incurs. Hey, depends on your upstream provider and the NAP you're talking about... for some "Large" providers and at least one NAP, the reverse is true. =-) davec

1 0

Re: Worldly Thoughts
by matthew＠scruz.net 12 May '96

12 May '96

Original message <9605110249.AA04557(a)wisdom.home.vix.com> From: Paul A Vixie <paul(a)vix.com> Date: May 10, 19:49 Subject: Re: Worldly Thoughts > > Quite a few CIX members operate this way. The interesting question in my > mind is whether the "big guys" (defaultless nets, for the purposes of this > discussion) think that this represents unfair competition or not. >-- End of excerpt from Paul A Vixie This is a _very_ interesting question in light of what I just posted... the CIX has the (odd, these days) feature that peering is mandatory for all, and so large providers don't get to choose whether or not they want to haul traffic across the country for these people. -matthew kaufman matthew(a)scruz.net ps. We'd already be at CIX if certain providers had more than a T-1's worth of bandwidth available out of there, specifically to take advantage of the "mandatory peering" situation. Heavily-loaded small pipes to interesting places aren't useful, though.

5 6

RE: Worldly Thoughts
by Jim Browning 12 May '96

12 May '96

>From: Erik Sherk[SMTP:sherk@uunet.uu.net] >> From: David Schwartz aka Joel Katz[SMTP:stimpson@stimpson.igc.net] >> Let's look at a hypothetical situation. ISP1 peers at MAE-E and >> buys transit from MCI there. Now they ask Sprint to peer with them. Let's >> look at how they reach sites on the west coast. > >This is a violation of the rules of Mae-East: it is not to be used for >customer connections. ISP1 must have a private connection to MCI. > >Erik Are you saying that MFS will not allow a private connection between two routers located at the MAE facility, even if the connection is _not_ made using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP) connection between the two routers?? If so, I haven't seen any documentation to that effect... -- Jim Browning

4 3

Re: Worldly Thoughts
by Dave Curado 12 May '96

12 May '96

> Let me turn the question around a bit. Suppose N small providers peer > at M places and together represent p% of the Internet. If they simply > appear at one NAP and don't contract for transit, they may reach > 100%-(%p/(M-1)) of the Internet. Is that something to encourage? If > they must contract for transit and as a result reach all major > interconnects, they get 100% (possibly minus a small epsilon for other > reasons). They then don't need to be at any of the NAPs. Are some > providers trying to show up at one NAP only with the aim of not > contracting for transit through anyone even though they can't really > reach others like themselves at a different interconnect? Or, possible some small providers buy a multi-megabit circuit from a large provider who gives them transit. The small provider then connects at a single NAP and picks up bilateral peering sessions with a bunch of people there. The result is offloading traffic from their "transit link", which stands a good chance of being priced as a "burstable" link. (pay for what you use) That gives the small provider an economic incentive to operate in this manner. No comment on whether this is a good idea or bad, but I understand the thinking. davec

3 2