May 1996 - Test - lists.nanog.org

Re: topological closeness....
by Hank Nussbacher 14 May '96

14 May '96

On Tue, 14 May 1996 10:09:44 +1000 Geoff Huston wrote: >At 6:15 PM 13/5/96, Vadim Antonov wrote: >>Cacheing appears to be the only sane way to distribute >>load. You always know where the closest cacheing server is. > >not even this is the case - you can guess but that may not always >work! > >If I could _enforce_ caching by traffic interception then >I could construct vaguely logical cache structures as an ISP. AS378 does exactly that. It blocks port 80 to abroad and forces everyone to the Netscape proxy servers it runs (2 of them in a load balance fashion with DNS set to point to only one if the other fails). AS378 is the Israeli University academic network of 7 universities. > >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. Not unless you don't have a choice :-) Go to: http://www.tau.ac.il/Shiber/May96/13May96 There you will find their numbers for yesterday. Port 80 now consumes 54% of all traffic. > >geoff > > Hank

1 0

Re: topological "closeness" (RE: Web o' Wonder)
by Justin W. Newton 13 May '96

13 May '96

At 03:04 PM 5/13/96 -0700, Matthew Kaufman wrote: >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 Yep, its much cheaper for me to buy another ds-3 or so than to worry about legal reprecussssions from proxying. This is something that has to be fixed. Justin Newton * You have to change just to stay Internet Architect * caught up. Erol's Internet Services *

1 0

NANOG ANNOUNCEMENT: Future Dates and Locations
by William B. Norton 13 May '96

13 May '96

Hi Everyone - Thought you'd like to know that our fall meeting is set. Here's the schedule for the next two meetings: May 30-31 Washington DC hosted by the CIX @ George Washington University Oct 24-25 Ann Arbor, MI hosted by Merit @ University of Michigan Union Cheers - Bill ---------------------------------------------------------------------------- ----- William Norton <wbn(a)merit.edu> (313) 936-2656

1 0

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

13 May '96

Well, i simply pointed out that solution based on *hosts* choosing the best paths in global networks is not going to work. It is in the same category as source-based routing. The network is simply too large for end-hosts to be able to make any useful decisions. I though that was understood long time ago, so nowadays resolvers do not even attempt to guess which address is best in case of multihomed hosts (beyond obvious directly-connected network trick). Pinging all addresses may be worse than just talking to a random server. To make any meaningful measurement you need to send many dozens of probe packets. Incidentally, that is about as much as the average WWW exchange takes. So the real solution is not to bother, and concentrate on demand-side cacheing. --vadim PS I would also be sceptical about attempts to "try" such things as perpetuum mobile or palm reading just on the chance that they may work. PPS The funny thing is that there's a hope that a good heuristic can be found -- since the network is rather hierarchal a good choice of topologically significant addressing is likely to produce situation in which bit distance between addresses is a good approximation of some "goodput" metric! This is very much the same effect as that of well-placed aggregation which produces routes close to optimal with a lot less information. Date: Mon, 13 May 1996 20:30:38 -0400 From: "Mike O'Dell" <mo(a)uunet.uu.net> Vadim, Yes, caching is a good idea (technically). And who said "AS path length" was a wonderful global metric??? just because the "usual suspects" BGP implementation generally does route selection based on that attribute doesn't mean that's the ONLY thing one can do. Depending on how much additional information one wished to supply about ASes, their general level of connectivity, and geographic location, one can conceivably produce hybrid metrics, probably heuristic, which reflect some sense of "performance". for example, the server could do round-trip measurements to "sufficiently interesting" ASes so that it could base its behavior on observations. the goal wouldn't be to do fine-grained decision-making, but if the "Bruce Springsteen Ticket Server" caused some reasonably long-lived congestion, it might be worthwhile redirecting some responses. The assumption is that this special DNS server might be concentrated on fielding responses for a special set of servers, like special Web servers (could be caches), and not general connectivity. So while few things are perfectly-universal solutions, the prospect of implementing heuristics that we all use today in getting a sense of how things are going, and what to try when the first guess is hosed, seems like a worthwhile attempt. some will work better than others. that is neither news, nor a reason to not try it. -mo

3 2

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

13 May '96

"Public cacheing" has little merit, as efficiency of cacheing decreases when covered population grows beyond some threshold (i.e when diversity of requests overwhelms the cacheing capacity -- process better known as "thrashing"). On the other side, small populations do not produce aggregatable demand patterns. I.e. it looks like that ISP-provided cache servers would be optimal. Conviniently, that allows to sidestep the problem of finding cache servers. When you never talk to other provider's cacheing servers you don't need to locate them. There are two ways to do distribute load: "supply side" caches (like secondary DNS servers) and "demand side" caches (like cacheing proxy servers). The supply-side cacheing has a fundamental problem is that you cannot tell which supply-side server is best. So much is clear from the DNS saga. --vadim

2 1

Re: topological closeness....
by gih＠aarnet.edu.au 13 May '96

13 May '96

At 6:15 PM 13/5/96, Vadim Antonov wrote: >Cacheing appears to be the only sane way to distribute >load. You always know where the closest cacheing server is. not even this is the case - you can guess but that may not always work! If I could _enforce_ caching by traffic interception then I could construct vaguely logical cache structures as an ISP. 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. geoff

3 2

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

13 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 13 May '96

13 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 13 May '96

13 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