I don't know if the chairs mind this LISP specific discussion, but if
not, we can take this over to the [email protected] mailing list.
Dino
On Nov 18, 2009, at 7:45 AM, Florin Coras wrote:
Noel Chiappa wrote:
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.)
I used exactly the same definition as you did, it seems that ALT
sometimes is faster than the one way delay from the ITR to ETR
(indeed we considered the latency from MS to ETR as 0 or in other
words, it is negligible when compared to the other latencies on the
path). I would go on to say that this can happen in current Internet
(overlays may be faster than underlying routing) but one could argue
that iPlane provided misleading information also. Notice though that
their number is relatively small, approximately 10%.
> 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.
Indeed, simplicity is one of NERDs characteristics and by storing
Map-Servers in the database you gain architectural benefits /less
updates at the cost of increased latency(from 0 to RTT). Maybe
packets could be forwarded by Map-Servers to ETRs (someway similar
to Data Probes in ALT. I know the group didn't like them). This
wouldn't imply, as with ALT, a long stretch of GRE tunnels but
native RLOC routing to the Map-Server and from there to the ETR.
Moreover, this last "segment"(from MS to ETR) would usually be
short. The most common exception would be the mobile nodes but this
triangular routing happens for the first packet only. Sorry if I'm
rehashing some closed threads.
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.
Since this in relation with our simulations and off topic we can
take this off list.
> 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).
Point taken. My misunderstanding.
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.
Well ALT doesn't cache Map-Servers but when the authoritative Map-
Server changes you need the BGP overlay to reconverge. For a
worldwide ALT you may also have a certain time of downtime(probably
more than 2 RTTs) for a domain(?)
Florin
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
