Cache-as-cache-can
To cut a long story short, I was just wondering if people could extrapolate their feelings regarding commerical Web Cache solutions. In terms of the good, the bad and the ugly. At the moment I'm left with 'two goods' Network Appliance's NetCache and Inktomi's Traffic Server and would appreciate some input to sort them out. -Michael -- Michael Haba <m.haba@magnet.at> Telenor Magnet - Internet at Work
In article <19981116200208.A27675@magnet.at>, Michael Haba <m.haba@magnet.at> wrote; } To cut a long story short, I was just wondering if people could extrapolate } their feelings regarding commerical Web Cache solutions. In terms of the } good, the bad and the ugly. } } At the moment I'm left with 'two goods' Network Appliance's NetCache and } Inktomi's Traffic Server and would appreciate some input to sort them out. I don't think there is major difference in caching, but some appliance have some problem in their routing. NetCache learns it from icmp redirect or rip1 which is quite poor for redundant network topology. I don't know about CacheFlow quite well, but it seems to speak rip1 at most. I believe they should speak ospf at least, if they run in a large isp. As for inktomi, there may not be any routing problem since it runs on some unix boxes, but it cannot handle so many connections simultaneously like NetCache or CacheFlow. -- Katsuhiro Kondou
We performed a number of tests with most all the vendor's products. Considering that most all the vendor's are represented on this list, I do not want to get into a p*ssing contest on a public list as to who has the best cache. We found important a number of items to consider with Web Caching. 1) Accuracy. If the served page is not the requested page, your customers will let you know. 2) Transparency. As long as your customers don't care it's there then everything is okay. When a Web Cache hangs up and black holes your Web traffic, that's a bad day. There are some layer 4 switches out in the marketplace (Foundry and Alteon) who redirect Web requests and run port 80 keepalives. 3) Availability. You don't want a sub-tera Web Cache subject to a single disc failure. Layer 4 switches also take care of your Web Cache cluster keeping flows and content contiguous. 4) Performance. There are a number of factors including max sessions, access speed and a few others to consider. Bottom line is that Web performance is a perceived service and is often subjective. 5) Also realize that Web Caches do interesting things in switched networks where 60-75% of your traffic belongs to a single IP address. Equal cost IGP metrics avail nothing. 6) The goal of Web Caching is not to reduce line utilization. We found some cases where line utilization maxed when we added the Web Cache. Having a 100Mbps box proxying all Web traffic can seriously expand TCP Windows as opposed to a typical modem which introduces serialization delay. Our goal was to give better international Web performance to customers while also making the most intelligent use of the international resources by removing redundant information. Interestingly enough, we also have seen a reduction of 20% TCP retransmissions to less than 2% on the core. -eric On Tue, 17 Nov 1998, Katsuhiro Kondou wrote:
In article <19981116200208.A27675@magnet.at>, Michael Haba <m.haba@magnet.at> wrote;
} To cut a long story short, I was just wondering if people could extrapolate } their feelings regarding commerical Web Cache solutions. In terms of the } good, the bad and the ugly. } } At the moment I'm left with 'two goods' Network Appliance's NetCache and } Inktomi's Traffic Server and would appreciate some input to sort them out.
I don't think there is major difference in caching, but some appliance have some problem in their routing. NetCache learns it from icmp redirect or rip1 which is quite poor for redundant network topology. I don't know about CacheFlow quite well, but it seems to speak rip1 at most. I believe they should speak ospf at least, if they run in a large isp. As for inktomi, there may not be any routing problem since it runs on some unix boxes, but it cannot handle so many connections simultaneously like NetCache or CacheFlow. -- Katsuhiro Kondou
Eric Dean <edean@gip.net> writes:
Our goal was to give better international Web performance to customers while also making the most intelligent use of the international resources by removing redundant information. Interestingly enough, we also have seen a reduction of 20% TCP retransmissions to less than 2% on the core.
This point is very, very important in most international ISP situations. The problem comes, in our experience, from customers with routinely saturated lines. The effect of "thousands of nibbling mice" (to paraphrase Sean Doran), meaning lots and lots of concurrent sessions from dialup or slow LAN users, means that normal TCP backoff doesn't work well. We can add CAR on the interface to maximize utilization, and save our router buffers, but the drops and retransmissions are still there. As expected, packets are lost at our border router facing such customers. However, for the data coming in from an international source (on an unsaturated international link), the retransmissions cause double traffic on the international line. Adding the cache effectively displaces the source of retransmissions from the (overseas) origin web server to the (local) cache server. We see traffic reductions due to both the caching effect, which can be significant, and due to the displacement in retransmissions. The customer still sees the same level of packet loss, since his line is still overloaded, but that traffic is served from the local cache and thus does not need to come over the expensive international link. -jem See http://www.data.com/issue/981107/crisis.html to learn more about Dacom BORANet
On Mon, 16 Nov 1998, Eric Dean wrote:
We performed a number of tests with most all the vendor's products. Considering that most all the vendor's are represented on this list, I do not want to get into a p*ssing contest on a public list as to who has the best cache.
We found important a number of items to consider with Web Caching.
1) Accuracy. If the served page is not the requested page, your customers will let you know.
2) Transparency. As long as your customers don't care it's there then everything is okay. When a Web Cache hangs up and black holes your Web traffic, that's a bad day. There are some layer 4 switches out in the marketplace (Foundry and Alteon) who redirect Web requests and run port 80 keepalives.
A related issue is correctness. From what I have seen of a product from a certain large router vendor, it does really stupid things like does not allow any persistent connections, breaks HTTP/1.1 chunked connections (well, actually worse: caches the chunked response so HTTP/1.0 clients that get the cached response see garbage) because they are too (lazy|dumb|rushed|etc.) to read a RFC, etc. You need to be _VERY_ careful when evaluating transparent proxies to see if the implementor actually knows anything at all about HTTP. Unfortunately, this can require you have a better than average knowledge of HTTP to begin with. I just really have trouble with "transparent proxies". The concept is bad (magically messing with traffic, that may not even be HTTP but may simply be sent over port 80 to get through filters, without the user being able to do a thing about it), and the implementations that I have seen are bad. The real long term solution is to provide better mechanisms where clients can automatically use a proxy if they should.
On Tue, Nov 17, 1998 at 07:53:18AM +0900, Katsuhiro Kondou wrote:
In article <19981116200208.A27675@magnet.at>, Michael Haba <m.haba@magnet.at> wrote;
} To cut a long story short, I was just wondering if people could extrapolate } their feelings regarding commerical Web Cache solutions. In terms of the } good, the bad and the ugly. } } At the moment I'm left with 'two goods' Network Appliance's NetCache and } Inktomi's Traffic Server and would appreciate some input to sort them out.
I don't think there is major difference in caching, but some appliance have some problem in their routing. NetCache learns it from icmp redirect or rip1 which is quite poor for redundant network topology. I don't know about CacheFlow quite well, but it seems to speak rip1 at most. I believe they should speak ospf at least, if they run in a large isp. As for inktomi, there may not be any routing problem since it runs on some unix boxes, but it cannot handle so many connections simultaneously like NetCache or CacheFlow.
Why use things like this, use a default route to a HSRP address ... /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
In article <19981117091400.D9778@skriver.dk>, Jesper Skriver <jesper@skriver.dk> wrote; } Why use things like this, use a default route to a HSRP address ... That could be. But they (appliance venders) haven't shown it at this point, afaik. They simply shows a veiw of cache appliance and l4 switch sitting between 2 routers. Why? -- Katsuhiro Kondou
There seem to be three solutions for transparent web-caching: 1 a web-cache between two routers, all traffic is routed through it. 2 a l4 switch between two routers, all traffic is routed through it. The l4 switch redirects web-requests to a www-cache. 3 a web-cache connected to a router which uses policy routing to direct web-requests to it. 1 is extremely ugly and impossible at high traffic levels 2 is an extra device in your network which needs to be managed and is often difficult to implement in a WAN environment (our core routers don't have (fast-)ethernet interfaces.) 3 is the preferred solution but you need to run 11.3 or 12.0 for it. These software versions support fast-switched policy routing. Most ISPs currently rely on 11.1CC features and thus can not upgrade to 11.3. The wait is thus for a stable release of 12.0. -- Steven In your mail from 17-11-1998 you write:
In article <19981117091400.D9778@skriver.dk>, Jesper Skriver <jesper@skriver.dk> wrote;
} Why use things like this, use a default route to a HSRP address ...
That could be. But they (appliance venders) haven't shown it at this point, afaik. They simply shows a veiw of cache appliance and l4 switch sitting between 2 routers. Why? -- Katsuhiro Kondou
The fourth solution is licensing WCCP http://www.cisco.com/warp/publlic/146/november98/17.html On Tue, 17 Nov 1998, steven hessing wrote:
There seem to be three solutions for transparent web-caching: 1 a web-cache between two routers, all traffic is routed through it. 2 a l4 switch between two routers, all traffic is routed through it. The l4 switch redirects web-requests to a www-cache. 3 a web-cache connected to a router which uses policy routing to direct web-requests to it.
1 is extremely ugly and impossible at high traffic levels 2 is an extra device in your network which needs to be managed and is often difficult to implement in a WAN environment (our core routers don't have (fast-)ethernet interfaces.) 3 is the preferred solution but you need to run 11.3 or 12.0 for it. These software versions support fast-switched policy routing. Most ISPs currently rely on 11.1CC features and thus can not upgrade to 11.3. The wait is thus for a stable release of 12.0.
-- Steven
In your mail from 17-11-1998 you write:
In article <19981117091400.D9778@skriver.dk>, Jesper Skriver <jesper@skriver.dk> wrote;
} Why use things like this, use a default route to a HSRP address ...
That could be. But they (appliance venders) haven't shown it at this point, afaik. They simply shows a veiw of cache appliance and l4 switch sitting between 2 routers. Why? -- Katsuhiro Kondou
I agree. You probably don't want these boxes doing more than a simple default route. For that, rip1 or static+HSRP are fine. Let routers route.
I don't think there is major difference in caching, but some appliance have some problem in their routing. NetCache learns
Why use things like this, use a default route to a HSRP address ...
In article <m0zfoVs-0004N3C@maya.whs.verio.net>, jzeeff@verio.net (Jon Zeeff) wrote; } I agree. You probably don't want these boxes doing more than a simple } default route. For that, rip1 or static+HSRP are fine. Let routers route. There are three problem even if above case is in use. 1 Cache appliance receives icmp redirect, if the gateway is not suitable to go. And the disaster happens, when the redirected router is down. 2 We see the same packet twice, if the packet redirected. This may lead higher cpu usage for the router. -- Katsuhiro Kondou
Jesper Skriver wrote:
On Tue, Nov 17, 1998 at 07:53:18AM +0900, Katsuhiro Kondou wrote:
In article <19981116200208.A27675@magnet.at>, Michael Haba <m.haba@magnet.at> wrote;
} To cut a long story short, I was just wondering if people could extrapolate } their feelings regarding commerical Web Cache solutions. In terms of the } good, the bad and the ugly. }
Why use things like this, use a default route to a HSRP address ...
Because you move your single point of failure back to the cache ethernet interface. Not a great tragedy if you've got a decent keep-alive from your l4 switch, but you lose all caching. Many of the applicances have dual ethers, but none (to the best of my knowledge) have implemented a failover. My preference is also for a load balance between two ethers, with failover on fault detection - but for the moment I'd be real happy with a simple failover. Note that this does not apply to the platform-based systems (e.g. Inktomi). daniel rothman
participants (9)
-
Daniel Rothman -
Eric Dean -
jem＠xpat.com -
Jesper Skriver -
jzeeff＠verio.net -
Katsuhiro Kondou -
Marc Slemko -
Michael Haba -
steven hessing