> From: Florin Coras <[email protected]>
> You can find some results that we presented
Very useful work - thanks for pointing me at that. Is there a paper being
done about this work? It would be very good/useful to have one.
> The figure you are looking for is on page 7.
Well, being presentation slides, they aren't quite as thoroughly described as
one would like (as a paper would be)... I assume the "RTT" is the RTT to the
destination EID? And the "ALT" is the time to get a mapping for a given EID
back from the ALT?
> 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.
You seem to be using a definition of 'stretch' where it is '((the ratio
between the actual path and the optimal path) - 1)'? (Since unless it is
normalized, in 100% of the cases the stretch will be >= 1.0, i.e. your comment
of "in 90% of the cases [it] is higher than 1" would not seem to make sense
without the normalization.) In other words, if I have understood this
correctly, you're saying that in 90% of the cases, the time to get a mapping
is more than twice the RTT to the destination EID?
It does appear from the graph on page 7 that although the stretch is larger
than 1 (using your definition), it's not much larger than 1 - e.g. at
ECDF=0.3, the RTT seems to be about 200, whereas the ALT time seems to be
about 500. This is only a bit higher than I would have guessed, but still not
bad.
(For this result to be useful to answer my original question, we will have to
assume that the RTT to the authoritative map-server is roughly the same as
the RTT to the EID itself, i.e. that the map-server is roughly co-located
with the destination.)
> So to answer your statement, based on these results, I think NERD does
> a better job at minimizing the delay to obtaining a mapping.
My previous message was not about NERD, it was about the suggestion that we
cache the location of the authoritative mapping-server...
> A NERD version that caches Map-Servers can offer mobility support
That's an interesting variant of the 'Classic NERD' - there would be less
churn, because only changes in the assignment of an authoritative map-server
for an EID would require updating the database. I don't have any good sense
of how big a drop in the update rate that would translate too, though,
although my _guess_ would be that it would be significant. However, on the
downside (as opposed to Classic NERD), you'd still have an RTT delay if you
got a cache miss on the mapping itself.
Overall, compared to, say, ALT, I'm not sure a decrease of a little more than
50% (on average) in the time to get a mapping would be that useful, though?
200 ms, 500ms, would the users really notice? Other systems (e.g. something
like CONS, with intermediate caching) might have mapping request response
times of significantly less than an RTT (especially for popular destinations,
which would more likely be in the intermediate caches).
Also, it might also be that we could get a significant speedup in ALT by
optimizing the topology of the ALT - I note that your simulation shows that
basically all lookups would traverse the entire 6-node ALT paths in your
assumed ALT hierarchy. E.g. your assumed hierarchy only has ~256 nodes at
Level 2 - it might be better to fully mesh them, and do away with the top
layer, which would reduce the average path from 6 hops to 4. And I wonder how
your ALT servers were laid out (in terms of the topology), since clearly the
layout of the ALT servers will affect the amount of stretch; a better layout
(perhaps with some replication, so that a Layer 3 box talked to several Layer
2 boxes) might reduce the stretch even more.
> 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?
Again, my comments were not in the context of NERD, but in the context of
caching the authoritative mapping-server (as opposed to caching the mapping
itself).
Caching the authoritative mapping-server is not a problem for other systems
_iff_ those systems don't cache that. E.g. ALT doesn't, and I don't think
CONS did either.
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
