- Test - lists.nanog.org

RE: decreased caching efficiency?
by Roeland M.J. Meyer 22 Oct '00

22 Oct '00

Christian, I invite you to www.photoloft.com Each album is dynamic and the site uses FlashPix technology. Have fun with it. > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > Sent: Friday, October 20, 2000 12:14 PM > To: nanog(a)merit.edu > Subject: Re: decreased caching efficiency? > > On Fri, Oct 20, 2000 at 11:59:58AM -0700, Travis Grant wrote: > [..] > > Commerce sites are also dependent on dynamic technology > that cannot be > > cached. Although you will find sites that are entirely > static (buy.com & > > etoys.com) you will generally find that these models are > based on volume and > > that the majority of these sites have never seen a dollar > in profit. However > > the profitable boutique type sites like eStyle.com, are > entirely dynamic. > > Margins are protected by a contractual product line. When > you place an > > order, a query verifies inventory prior to final checkout. > In addition, > > product pages indicate whether items are in stock or not. > You cant cache > > these types of sites. > [..] > > Each and every button, product image etc could be cached, > regardless of the > dynamic nature of the website. Images cost cycles, bw. > > [..] > > Most caching implementations will cost way more than the > bandwidth costs > > they avoid. > > You get no argument there ;-). I never felt that you could > ever justify > caching in terms of bandwidth savings. You can only justify > in terms of > improving a users experience. And in that sense, you are > giving considerable > resources to a content origin, and a free service to them. > > That's why the CDN strategy is much more attractive, where > you have a hosting > relationship of some kind with the content origin. > > [..] > > load on the DB servers. But TTLs will usually have to be > set pretty low (2 > > seconds) in order to do this and the technologies will have > to be catered to > > web development environments (like cacheflow and ASP). > [..] > > Hmm, if you cache what I suggest above, that's not really > neccessary... No? > > Cheers, > Chris > > -- > Christian Kuhtz > Architecture, BellSouth.net > <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Atlanta, GA > "Speaking > for myself only." >

1 0

DC Zoning Commission planning to limit carrier hotels?
by rdobbins＠netmore.net 21 Oct '00

21 Oct '00

http://washingtonpost.com/wp-dyn/articles/A41553-2000Oct19.html ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

3 2

Cheapest ethernet switch with monitor/mirror port?
by Dan Hollis 21 Oct '00

21 Oct '00

Looking for the cheapest ethernet switch with a monitor/mirror port. Recommendations? -Dan

3 2

RE: decreased caching efficiency?
by Travis Grant 20 Oct '00

20 Oct '00

William, Where does caching make sense? Static assets that can be stored on the edge closest to customers ie images, audio, video. These needs are served by your Akamais, IBeams, and Evokes. One other place where it makes sense to cache, in your Corporate environement. There will probably be a flux point for cost savings in respect to bandwidth if a company is able to get the majority of web traffic to remain on the LAN. But in regards to a caching architecture for your web site. Sites that have any revenue tied to advertising will benefit highly from knowing exact demographics, exact visitor counts, etc... In addition advertisers pay more for "targeted advertising" and targeted advertising is done with Dynamic technologies that can not be cached (the banner can be cached and await retrieval). Push technologies are to the advertising industry as napster is to the music industry. Acting as a catalyst in '96, the advertising industry recognized the benefit of targeted advertising that push technologies offer and embraced the internet. There are entire business models built on this principle (pioneers ADFORCE - formerly IMGIS, recent newbies alladvantage, mvalue, etc...). Commerce sites are also dependent on dynamic technology that cannot be cached. Although you will find sites that are entirely static (buy.com & etoys.com) you will generally find that these models are based on volume and that the majority of these sites have never seen a dollar in profit. However the profitable boutique type sites like eStyle.com, are entirely dynamic. Margins are protected by a contractual product line. When you place an order, a query verifies inventory prior to final checkout. In addition, product pages indicate whether items are in stock or not. You cant cache these types of sites. Granted this architecture is hard to scale, but they represent a rare breed of commerce vendors making cash. And by the way saving bandwidth is not justified for the majority of the market. 80% of deployed sites are sucking less than 2Mbps in monthly fees. Most caching implementations will cost way more than the bandwidth costs they avoid. Some dynamic site architectures will benefit from caching if the cache product is able to reduce the number of web servers required in a farm and/or if the cache engine working with the web farm is able to reduce the load on the DB servers. But TTLs will usually have to be set pretty low (2 seconds) in order to do this and the technologies will have to be catered to web development environments (like cacheflow and ASP). Travis Grant System Architect www.kore.com -----Original Message----- From: William Allen Simpson [mailto:wsimpson@greendragon.com] Sent: Friday, October 20, 2000 7:04 AM To: nanog(a)merit.edu Subject: Re: decreased caching efficiency? Dana Hudes wrote: > > I vehemently disagree with the statement that impressions do not make any sense, > only clickthroughs. There is such a thing as brand awareness, a situation where > a banner ad is good for itself even if it doesn't lead to click through. > Of course, in that case, the benefit is to the advertiser. That is, they get the benefit, but you don't get paid. Not my problem. That seems to follow "not make any sense", but YMMV. > It is NOT for YOU to decide what business model makes sense for MY > business relationship with MY advertisers. > Nope. You can have any business relationship you'd like. But, by the same token, it is not for *YOU* to decide that *I* have to pay to support YOUR business decision. Last time I looked, there's no constitutional right that guarantees that you can make money. > I pay my ISP to carry IP packets around. But, you don't pay ME to carry your IP packets around. My customers pay me. I pay my upstream. Therefore, I pay my upstream as little as possible. > In some cases certainly your cache is in fact a copyright violation. > Interesting, if true. Perhaps you could provide a citation? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 3

Re: DC Zoning Commission planning to limit carrier hotels?
by Steve Sobol 20 Oct '00

20 Oct '00

"John K. Doyle, Jr." wrote: > Various cities in the Bay Area are rapidly enacting anti-.com zoning > ordnances. This isn't specific to data centers. The problem is that, out > here at least, the .com explosion is of sufficient magnitude that it has a > tendency to wipe out "business districts." What happens is that the .com > companies are WAY better funded than your average shoe-shine stand, burger > joint, or even neighborhood pharmacy. So, they can afford to pay way more > rent than a traditional business can. Pretty soon, you look up and there > is NO retail to be seen anywhere in the business district. > > Now imagine the ripple effect. I've read about this phenomenon in the SFO area, although what I read mentioned residential housing. (Several friends who live there have confirmed what I've read). Wouldn't it be better to enforce an anti-price-gouging law that capped the amount of rent landlords could charge? -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Linux Instructor, PC/LAN Program, Natl. Institute of Technology, Akron, OH sjsobol(a)NorthShoreTechnologies.net - 888.480.4NET - 216.619.2NET

1 0

RE: decreased caching efficiency?
by Roeland M.J. Meyer 20 Oct '00

20 Oct '00

> Also don't confuse profit with revenue. A mistake that many make. One can have lots of revenue and still have negative profits.

1 0

Re: decreased caching efficiency?
by Dana Hudes 20 Oct '00

20 Oct '00

I can point out plenty of examples of large sites which do not work without JavaScript. Also don't confuse pofit with revenue. On Fri, 20 Oct 2000, Hendrik Visage wrote: > On Fri, Oct 20, 2000 at 12:43:51PM -0400, Dana Hudes wrote: > > > > > > ----- Original Message ----- > > From: "Majdi S. Abbas" <msa(a)samurai.sfo.dead-dog.com> > > To: "Dana Hudes" <dhudes(a)hudes.org> > > Cc: <nanog(a)merit.edu> > > Sent: Friday, October 20, 2000 12:33 PM > > Subject: Re: decreased caching efficiency? > > > > > > > > > > On Fri, Oct 20, 2000 at 10:24:27AM -0400, Dana Hudes wrote: > > > > No, you are interfering with my revenue stream by preventing > > > > my getting credit for the banner impression. > > > > > > Tough. Banner ads aren't a guaranteed form of revenue. > > > > Neither is being an ISP a guarantee of revenue. > > Depends on a couple of factors, but it could be a pretty decent > form of "guaranteed" revenue. > > > > How would you feel if I said my cache at home filters banner > > > content out? > > > > I hope my JavaScript would detect this and refuse to display the photograph. > > Sofar you've given us LOTS of reasons NOT to visit your site (BTW, url > to exclude from our caches ;^) > > This will actually make several people turn away from your site, as > people don't always like java/javascript and have it actually turned > off, like when browsing via a Nokia 9110, lynx etc. > > Hendrik >

1 0

The Cidr Report
by Tony Bates 20 Oct '00

20 Oct '00

This is an auto-generated mail on Fri Oct 20 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 20Oct00 0) General Status Table History ------------- Date Prefixes 131000 88713 141000 88736 151000 88773 161000 88779 171000 88976 181000 89084 191000 89049 201000 89411 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 8803 Number of ASes announcing only one prefix: 5049 (2823 cidr, 2226 classful) Largest number of cidr routes: 930 announced by AS701 Largest number of classful routes: 1133 announced by AS701 1) Gains by aggregating at the origin AS level --- 20Oct00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 431 152 279 64.7% BCnet Backbone AS1221 590 439 151 25.6% TELSTRA-AS AS816 595 454 141 23.7% UUNET Canada (ASN-UUNETCA-AS4) AS9269 177 46 131 74.0% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS9304 130 17 113 86.9% Hutchcity AS6429 222 112 110 49.5% FirstCom Internet AS7545 159 55 104 65.4% TPG Internet Pty Ltd AS8013 467 364 103 22.1% PSINET-CA AS7046 355 254 101 28.5% UUNET-CUSTOMER AS4755 200 101 99 49.5% Videsh Sanchar Nigam Ltd. India AS705 356 259 97 27.2% ALTERNET-AS AS7657 313 220 93 29.7% The Internet Group Limited AS7496 126 35 91 72.2% Power Up AS174 539 453 86 16.0% Performance Systems International AS4293 341 259 82 24.0% Internal ASN for C&W AS13999 91 9 82 90.1% UNKNOWN AS701 1133 1052 81 7.1% Alternet AS6595 137 56 81 59.1% DODDSEUR AS3908 251 172 79 31.5% Supernet, Inc. AS577 249 176 73 29.3% Bell Backbone AS724 220 153 67 30.5% DLA-ASNBLOCK-AS AS7018 574 508 66 11.5% AT&T WorldNet Service Backbone AS5106 100 37 63 63.0% AADS-COLUMBUS AS226 168 106 62 36.9% USC/Information Sciences Institut AS3749 121 61 60 49.6% TECNET AS16758 63 6 57 90.5% UNKNOWN AS8151 181 126 55 30.4% UNINET-MX AS8895 97 43 54 55.7% Saudi Arabia AS AS7568 78 24 54 69.2% C.S. Communications Co., Ltd. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: decreased caching efficiency?
by Simon Leinen 20 Oct '00

20 Oct '00

>>>>> "ld" == Lincoln Dale <ltd(a)interlink.com.au> writes: > caches exist for multiple reasons -- > [1] to make things faster > [2] to save bandwidth > [3] to achieve more "goodput" in network transactions. > [4] to operate at layers-8 and 9 (filtering) [...] > in many cases, people significantly underestimate the effect of #3 - > and it isn't easily measured. it is the effect of a "good" tcp stack > cutting down end-to-end tcp retransmissions when the "last mile" hop > is congested. Not just when it is congested... whenever the proxy (I'm deliberately not talking about "caches"---even a cacheless proxy would have this effect) has RTTs to the origin server and the browser which are both lower than the "e2e" server<->browser RTT, then the TCP control loop will react faster to changing network conditions. This includes faster "ramping up" to available bandwidth, and higher achievable throughput if the same window size is used. Note also that proxies can affect goodput adversely, for example when both the origin server and browser host support larger TCP window sizes than the proxy. This artificially limits throughput when there's little or no congestion over paths with high RTT. I think this is quite common because it is easier for browser hosts than for proxies to support larger TCP windows---proxies have to support high numbers of concurrent TCP connections, and using large windows may incur very significant kernel memory overhead unless OS developers do clever memory-allocation things. -- Simon.

2 1

RE: the new 6509 OSR
by baburn - Bart Burns 20 Oct '00

20 Oct '00

My understanding is that the ESR will serve as high-density aggregation for traditional WAN circuits. 56Kb to DS-3. The OSR will serve as high-density aggregation for DS-3 ot OC-192. Bart Burns Network Engineer Acxiom Corporation (501) 342-4167 email bart.burns(a)acxiom.com -----Original Message----- From: Neil J. McRae [mailto:neil@COLT.NET] Sent: Thursday, October 19, 2000 9:35 AM To: baburn(a)acxiom.com Cc: nanog(a)merit.edu Subject: Re: the new 6509 OSR I thought that the ESR was the new 75xx class box? Regards, Neil. [Charset iso-8859-1 unsupported, filtering to ASCII...] > We are about to purchase several of these OSR's. Here is what we know about > the OSR. If you look at the roadmap for the OSR, Cisco is positioning this > platform to be the next 75xx class device only it will be for high-speed > connectivity at DS-3 or greater. It will scale all the way to OC-192 or 10 > Gig Ethernet. The main reason we are looking at the OSR vs a plain jane > 6509 is because the OSR can serve as a high-speed ingress point to the MPLS > backbone that we are about to deploy. The OSR interfaces have deeper > interface buffers than the plain 6509. > > Bart Burns > Network Engineer > Acxiom Corporation > (501) 342-4167 > email bart.burns(a)acxiom.com > <<Bart Burns (E-mail).vcf>> [Attachment, skipping...]

3 2