Re: [RAM] The mapping problem: rendezvous points?

David Conrad wrote:
> There are numerous tradeoffs that have to be taken into account when 
> choosing where to do the mapping.  The closer to the host you get, the 
> less scope is affected by the mapping.  For example, if the mapping is 
> done for a "site", changing the mapping has the effect of instantly 
> changing the locator/ID mapping for all devices within the "site".  
> Move down to the host, and the change obviously only affects the one 
> host.

Right.  And while it is perhaps inelegant in some eyes, there may yet be 
room for two separate approaches: one on the host and one off the host 
and somewhere in the network.  It may be possible to extend LISP into 
the host as well.  Clear functional separation may provide us with 
several approaches to deal with the mapping.  In an experimental 
environment that would be a good thing.
>
>> Then there are security and continuity considerations.
>
> Agreed there are security considerations (I'm not sure what 
> "continuity" considerations are).  There are security considerations 
> in everything including both push and pull models of mapping 
> distribution.

Yes. Let's evaluate them.  When I say continuity, I mean, what happens 
when a router fails or comes into service.  Does its return to service 
mean that a bunch of name servers are about to be attacked?  Can it only 
but drop packets for the first few minutes because it needs to take the 
"suboptimal stretch"?  I'm talking about later versions of LISP here, 
for example, where there is no backup.

>
>>> In response I get vague handwaving about voice or video (I know from 
>>> personal experience that UDP-based NFS works fine in the face of an 
>>> initial packet delay of 10s of milliseconds) or descriptions about 
>>> classes of applications that would appear to be degenerate cases and 
>>> asymmetric routing that would likely have unpredictable performance 
>>> characteristics with pull or push.
>> You talk delay.  I talk loss.  Routers don't just keep packets lying 
>> around if they can't deliver them.
>
> How does that ARP thing work again?
ARP represents a millisecond delay.  Routers themselves ARP so rarely 
that it's not a factor.  What is a factor is when packets in the middle 
of a path are just dropped.

> Of course, this isn't really relevant as the only added delay in a 
> pull model would occur primarily during the initial session 
> initiation, e.g., when the domain name of the voice or video server 
> was being looked up or the connection initiation packet was being sent.

You cannot say with certainty whether we're in session initiation or at 
some other point.  In the case of a routing transition, the new router 
will have to query to restart the connection, causing seconds of delay.  
The same will occur when things transition back, if either the old 
router has lost its cache or has been down sufficiently long for the 
cache to expire.  During this period of time the router would need to 
make as many queries (and maybe more) as it has conversations going on.

Eliot

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram