Subject: Re: [rrg] NERD

From: [email-masked] (Noel Chiappa)
Date: Wed, 18 Nov 2009 00:10:46 -0500 (EST)

> From: Florin Coras <[email-masked]>

    > 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

---

From: Florin Coras <[email-masked]>
Date: Wed, 18 Nov 2009 16:45:32 +0100

> the RTT to the EID itself, i.e. that the map-server is roughly co-located
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%.
> 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.

> 2 boxes) might reduce the stretch even more.
Since this in relation with our simulations and off topic we can take 
this off list.
> caching the authoritative mapping-server (as opposed to caching the mapping
Point taken. My misunderstanding.
> _iff_ those systems don't cache that. E.g. ALT doesn't, and I don't think
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-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 18 Nov 2009 15:51:19 -0800

I don't know if the chairs mind this LISP specific discussion, but if  
not, we can take this over to the [email-masked] mailing list.

Dino

On Nov 18, 2009, at 7:45 AM, Florin Coras wrote:

> 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%.
> 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.
>
> Since this in relation with our simulations and off topic we can  
> take this off list.
> 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

---

From: Tony Li <[email-masked]>
Date: Thu, 19 Nov 2009 00:33:27 -0800

> not, we can take this over to the [email-masked] mailing list.

That would be much appreciated.

Thanks,
Tony