Noel, > However, if the mapping function moves closer to the servers, the cache size > will scale more reasonably. (A hand-wavy argument that the scaling will be > feasible is provided by noting that at the limiting case, a single server, it > can only support a limited number of TCP connections anyway, so it perforce > will be talking to a limited share of the network.)
I don't think that's even very hand-wavy. If a server can handle state for N simultaneous transactions, and the extra state per transaction to cache the mapping info is a small fraction of the total state per transaction, surely we can pick the cache lifetime so that the cache size also scales like N. Also, in the context of large-scale services, "server" these days means a rack or a room full of virtual servers, which are there precisely to deal with scaling like N. So it becomes necessary, not optional, to move the mapping cache to the places where state has to scale anyway. That takes it out of traditional networking equipment, I think. Regards Brian Carpenter _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
