Hello Noel, Sorry for the lengthy reply! Hope it proves useful. You can find some results that we presented at the IETF 75 meeting in Stockholm this summer, regarding the delay to obtaining a mapping from an ITR standpoint, here: www.ietf.org/proceedings/75/slides/lisp-4.pdf . Unfortunately these are not measured but are obtained through simulation over an Internet measured topology, because there is no *large* deployment of a mapping system, at least as far as I know. The figure you are looking for is on page 7. I would be happy to answer any other question regarding our experiment or provide other results.
It doesn't show well there (because of the scale) but there are cases when ALT offers a delay comparable to the one way delay from the ITR to the ETR. Unfortunately in 90% of the cases the stretch factor (ALT/RTT) is higher than 1. So to answer your statement, based on these results, I think NERD does a better job at minimizing the delay to obtaining a mapping. But I don't know if it would scale to a global mapping system so that is why I suggested it could be used for inter AS traffic engineering (the second level of LISP, that makes use of private mapping database between the AS-es). A NERD version that caches Map-Servers can offer mobility support (not useful in above mentioned case) because all the mobile nodes now have a fixed "rooted" point in the global RLOC Internet, the Map-Server (this is in fact the idea behind LISP-MN). This also addresses churn and/or problems due to old versions of the NERD database at ITRs (Map-Servers are not likely to change often). The drawback for this improved NERD is that it can't forward the first packet at line speed ( this might be against the purpose for which Eliot built it ). Nonetheless you mentioned that there is an increase in complexity when the authoritative Map-Server changes. Isn't this an issue with all mapping systems? Why do you think the situation is worse for NERD? Thanks, Florin Noel Chiappa wrote: > > From: Florin Coras <[email protected]> > > > Wouldn't it be better to have ITRs store the Map-Servers .. instead of > > the mappings? > > I'm not sure it would buy you that much, because you're still facing a > minimum of an RTT to the/an authoritative mapping-server, to get a new copy > of the mapping. > > I'm not sure how much larger the response-time would be if one went through > the full mapping cycle (i.e. starting from scratch), but _iff_ speed-of-light > delays are the primary component (as they are today, with the minimal > processing delays in the switches), then if the path through the resolution > hierarchy (since any resolution system other than 'every mapping server has > the entire mapping table' is going to be organized as a hierarchy) is not > _too_ far off from the optimal path to the authoritative mapping-server, > the single direct RTT should not be that much less. > > On top of that, there's a bit more complexity, because you also have to deal > with the situation where the cached mapping-server is no longer the > authoritative mapping-server for that identifier. > > It would be interesting to know if anyone has measured RTTs from any deployed > mapping systems, to see if my total guess (in the paragraph above) about > 'stretch' in the mapping system is correct. > > Noel > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
