- Test - lists.nanog.org

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

14 May '96

>one other solution (being implemented, I believe), is a DNS server >that listens to the BGP traffic, so it knows how far away things are, >and when you ask it, it can chose from multiple responses to pick >one "close". > > -mo The only problem that it does not work at all. Which WWW server is closer to me - one with BGP path 1239 3491 690 1333 (cnn.com) or one at 1239 1792 (www.cnc.ac.cn)? The second is in China, for God's sake! There ain't no such thing as global metrics. The only useful kind of metrics is administrative, and therefore they cannot reflect any real characteristics of paths. Even if there are uniform metrics, how do you tell which link is overloaded and which isn't? Cacheing appears to be the only sane way to distribute load. You always know where the closest cacheing server is. Now, there's a problem with coherency, but at least it can be done w/o magic. --vadim

4 3

Re: topological closeness....
by Mike Trest 14 May '96

14 May '96

Vadim Antonov wrote: >Cacheing appears to be the only sane way to distribute >load. You always know where the closest cacheing server is. >Now, there's a problem with coherency, but at least it >can be done w/o magic. Discovering the topology of a group of CACHE servers also needs some clarification. Typically, you only know your internal cache servers. There is a strong international focus on this topic. However, I cannot see how these can be of any "general public" value since a provider would construct a cache to benefit internal customers. My question remains, is this value to our customers and consequent reduction in extrnal traffic sufficient to justify the effort? The research says yes. What about actual experience in a real network? ..mike.. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1901 San Diego, CA 92121 Pager: 619 960-9070

1 0

Re: Worldly Thoughts - Regionalizing Peering
by Justin W. Newton 14 May '96

14 May '96

At 07:24 PM 5/11/96 -0500, Alan Hannan wrote: > > Toodles, > >] > 2. Even better, accept my routes into your network but only use them >] > within region... I know this isn't nearly as easy as #1, so I don't >] > expect it to happen, but it would be a significant performance benefit >] > for the local traffic your customers in the region are generating which >] > is headed towards me. Once outside the region, of course, you ignore the >] > direct routes from me and just give them to my transit provider. > 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. Another drawback to this model is that if you peer with people at one exchange and one exchange only you would only give them routes that are within the local region, and not all of your routes. This may be a problem. It may not. (Plus you could always just setup a system that marks where you peer with people at and have it allocate routes accordingly, i.e. if you only peer at one place you blow them everything there.) Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

2 1

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