Uh, watch out, there are packet flow descriptions here. I'm sorry to post something non-legal-related and non-inflammatory. If there's a better list for technical issues, someone please point me at it :-)...

As far as the asmetric routing issue, the traffic INSIDE the ISP isn't asmetric, and shouldn't need to be cached. I don't really see the problem here. (But it could be me.)

That's true but only depending on how you look at it. If the client and server are in the same IGP there is probably no benefit to be had from transparent caching -- though replication and optimal redirection would still have a place, at least in the larger IGP's. But if one end of the connection is outside the IGP (and it doesn't matter whether this end is the client or the server), and if the IGP has multiple border gateways, then hot potato routing really screws you since the two connections inside the TCP stream can potentially take different paths. If a stream is going to be intercepted, it must be by a device which sits in the path of both connections, since the sequence numbers of a connection are used in the ACK fields of the other connection. If you can do your interception in your customer's "tail" (the part of the customer's data path where all ingress and egress still uses the same links/routers) you're OK. But if you're sending a customer's segments out one path, which is intercepted by one device, and the ACKs or other inbound segments come in via some other path, which is not intercepted or is intercepted by some different device, then you are pretty much screwed.(*) This is one reason out of several why transparent caching is an access side issue, and why the server side caching has to be done with something more robust like replication and redirection. [ (*) yes I know the two devices can synch their sequence numbers with a back channel, or use predictable ones, but that slope is so slippery that it may as well be paved with vaseline -- let's just not go there, OK? ] -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul@vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)