Robert, On 16 Jul 2011, at 20:14, Robert Raszuk wrote: > Hi Damien, > >> Actually, the very nature of Internet traffic make this a non-problem. >> Indeed, the heavy tail nature of the spacial locality distribution in the >> Internet ensures that, in general, only the big networks will have to deal >> with a huge number of client. And if your network is big, it is very >> likely that it will have many entry points and that these entry point are >> topologically close to the clients meaning that each entry point will >> actually not have to deal with millions of clients. Don't forget that you >> have to think in term of locality with LISP. If you don't you will kill >> the paradigm. Not because it is bad but because your interepretation is >> incorrect. LISP is not BGP! So if you don't believe me about how the >> traffic is on the Internet, I think you can believe the harbor study (data >> from hexabytes of traffic in real networks). What does the study show? >> Simply that the traffic converges to a few buch of CDNs (actually the >> study shows much more than that, but only this point is important for >> now). > > I am a bit puzzled by your above points. You seems to be making a future > claims based on historical observations statistically averaged with time. I > am afraid the point Jeff is making is not about any average .. it's about a > peak. >
You are partially right as in the different studies, the cache load is considered on average, in general 1 minute. However the averaging periods are shorter than the TTL/timers used for the caches so the instantaneous size of the cache would not change dramatically (probably a 1 or 2 % increase). What could change more is the "churn" (i.e., the instantaneous cache size change) as we are smoothing the curves thus lowering the derivative of the underlying cache size function. So for the studied networks, the cache sizes obtained are very close to the reality (under our EID prefix attribution assumptions of course). > I think any solution by design must consider that even if I am a very small > home site my xTRs must be able to deal with millions of clients .. as this is > not query, but replies which will go into millions of Internet destinations > the moment google indexes some very popular content on my web server. Just > consider the case where I am multi-homed and my web queries are coming over > different ETR then my replies are taking ITR. I am not sure I understand perfectly what you mean. Why should a small home site would have millions of destinations? It would mean that you observe at least millions of flows within your small network. Even in campus networks like our university we do not observe millions of concurrent flows. In one day we have in general 3 million different IP addresses in our network and there is no mechanism to limit the traffic but more interestingly, during 5 minute periods, we observe peaks at around 60K to 70K concurrent destination addresses and peaks to 1.2M L3 flows and interestingly, from 5min time slots to 5min time slots, we can see big variations (having 60K destination then 20K then 40K ... is common) maning that actually the ground traffic that would stay in the cache for what ever TTL is not so important. Indeed, a top few (~ thousands) destinations are contacted all the time, while the rest could be seen as noise with short period of time (from a few seconds to a few hours). So a good cache eviction algorithm should solve most of the case. Regarding the cache size, I think that the mistake is in the specs, where it is recommended to have a TTL of one day. From the temporal locality of Internet traffic, we can say that this choice is meaningless. xTR should be able to fix themselves the TTL of the mappings they install in their cache (TTL_cache <= TTL_Map-Reply). Nevertheless, it is true that a site like google may have to deal with millions of mappings while indexing. I do not know how google work for indexing, but I presume that this million of pages are not indexed in one minute by a single machine. Probably that the indexing takes several hours (days?) and is from different machines with load balancers. Probably that the indexing of a site takes at much a few tens of minutes, the ITR could thus limit the TTL to that amount of time. In addition, if load balancers are actually used, one could imagine to use these LB directly as xTRs. Another case where you can observe peaks of destinations is with mails, if your server is attacked and becomes a relay for spams, it can potentially have to contact a huge number of destinations. It is a problem, but I think that the problem is not LISP but the way the server is managed. But you and Jeff are right that LISP has a big problem in case of sort of flash crowds. The question is to know what will die first, the cache or the services that are flash crowded. Such peaks can also be done with DDoS and this is why we are working on techniques to avoid spoofing with LISP. And yes, we have to be honest we do not have the perfect solution now for this problem. Thank you, Damien Saucez > > Many thx, > R. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
