Re: [RRG] ALT + NERD is inelegant & inefficient, compared to APT or Ivip

[David Conrad <drc@virtualized.org>]

Robin,

On Jan 23, 2008, at 6:03 PM, Robin Whittle wrote:
> I agree with you in some respects.  For LISP, the mapping data won't
> change at a huge rate, and even though the mapping data is more
> complex than for Ivip, the communications volume required is
> probably not a problem for ISPs and for larger routers.

Wouldn't it be more correct to say that if you make the assumption  
that the mapping data won't change at a huge rate and/or the map  
itself isn't overly large, then it is probably safe to say that  
communications volume won't be a problem.

The problem I personally have is that I don't feel comfortable in  
making either of those assumptions.  In fact, one might argue that  
making both of these assumptions is what has gotten us into trouble in  
the first place.

> What do you think of the idea of making that query server function
> available to nearby devices?

It is something I think should be explored.

> Anyone who believes in a pure ALT system must be expecting end-users
> to put up with initial packets being dropped or delayed so much as
> to be useless or worse than useless if and when they arrive.

I will note that back when Proteon was the router maker of choice, it  
was fairly common for the first packet in a new incoming conversation  
to get dropped due to the need to do an ARP lookup, yet people got by  
(most didn't notice).  As the technology improved, the need to drop  
packets waiting for ARP lookups was removed. It isn't clear to me why  
history wouldn't repeat itself.

> There are probably no free lunches, but there are combinations of
> techniques which work elegantly and efficiently by complementing
> and/or supporting each other.

As others have noted, the downside is that you're adding a fourth  
vector the the triplet of (rate, state, latency), namely complexity.   
It may be that this is necessary and a mixed model is the best way  
forward, but it is yet another factor in a "no free lunch" tradeoff.

> Probably the way to cope with the costs of handling large numbers of
> end-user-generated EID divisions (micronets) and mapping changes is
> is to have some kind of charging scheme for each mapping change.

I suspect along this path lay madness.  Assuming the imposition of a  
particular operational business model in order to alleviate a downside  
of an architecture hasn't worked very well in the past.

Regards,
-drc


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg