Hello, On 18 Jul 2011, at 10:12, Robert Raszuk wrote: > Hi Damien, > > Many thx for your reply. > > Let me clarify ... > >> 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. > > Yes. Imagine if you or me announce wiki-leaks-2 content on our IPv4/IPv6 home > web server. I think number of flows will explode. And imagine we are lucky > users of FTTH so no bandwith issue :) > > Moreover those may not be DOS or spoofing. Those may be legitimate addresses. > And I do not think the server will die. > > And I am not saying LISP will or will not be able to handle it. I am just > asking how it will handle it ;) Maybe the answer is to in the moment of > exceeding capacity threshold of any xTR push some of the traffic to few > bigger proxies ... just a thought. >
Thank you for the clarification, this is a nice example indeed! You are right that for such legitimate traffic there is problem as it can be assimilated to a flash crowd. In you particular example, I think that it is the Map-Resolver or the control plane itself that will cause the problems! If we consider the cache size it should be ok. If we have one million client *simultaneously* and that the system is stupid and stores the mapping records as-is, that all the requesters are IPv4 and have two rlocs, then 40MB of storage is required. It is especially what the small home routers have today, but it is not 1million times more than the memory they provide now, so it would not be too hard. But the control-plane in these routers would suffer and these boxes are in general pure software and have slow processors so I don't know if they will enjoy to update the cache at a rate higher than a few hundreds entries per second. To be honest I don't know what could be achieved by such devices. And even if they are able to deal with this speed, it will maybe be complicated for the boxes to find a MR that will not rate limit the number of requests. So this goes in the direction of Jeff saying that the churn problem should not be neglected. Thank you, Damien Saucez > Cheers, > R. > > > > 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
