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

[Tony Li <[e-mail]>]

Dave,

On May 8, 2007, at 11:18 AM, Dave Thaler wrote:

> I disagree with the word "everything".  The two high level choices  
> are:
>
> PULL: work on-demand (which results in deterministic loss and hence
> adversely affects applications) and cache the result for some time
>
> PUSH: learn enough information (which may or may not be everything)
> ahead of time so that one has enough information to immediately  
> forward
> a packet when it arrives.  It would be desirable to learn log(N)
> information (and everyone may not learn the same information).


Thanks for the summary.  I think we should also point out that there  
are a variety of hybrids, where some parts of the mapping are pushed  
and some parts of the mapping remain to be pulled.


> DHTs distributing log(N) information to each node are another type of
> PUSH, and don't have the scalability issues.


I'd claim that that's a hybrid, where you push information to some  
locations, but since no system has a full mapping, you end up pulling  
the needed entries at some point.  I agree that it avoids the  
scalability problem and hope folks take careful note of this.


> Rendezvous points as you suggest below are another type of PUSH, where
> the non-rendezvous points have a small amount of information, but if I
> understand you correctly, the RPs still have the same scalability  
> issues
> as flooding everything.


If I understand Iljitsch correctly, the rendezvous point is another  
hybrid model where full information about portions of the mapping are  
pushed to certain locations.  However, rather than pulling detailed  
information, the remainder of the network redirects traffic to the  
rendezvous point.  This trades off the latency of pulling the  
detailed information against additional stretch in the data plane  
(and latency there).

Again if I understood correctly, each rendezvous point would be  
responsible for only a fixed portion of the mapping, so there isn't a  
scalability issue.

Tony



>> Something like that may be useful in our problem space, too. The way
>> I imagine this is by having rendezvous points where the reachability
>> information for subsets of the network comes together. For instance,
>> as a large ISP, I could have a small number of routers handle a
>> certain /8 out of IPv4 space. All the other routers route their
>> traffic for this prefix to the closest one of the rendezvous routers
>> in question. These then forward the traffic as per more specific
>> routing information if possible, or encapsulate it if necessary.
>>
>> The rendezvous point is where traffic and routing information all
>> come together.
>>
>> Compared to an on-demand model, this has the advantage that there are
>> no delays and no caching issues. Compared to a flooding model, it has
>> the advantage that the full specific information is only required in
>> relatively few places. This can work with both a very small number of
>> very large routers, or a much larger number of much smaller routers,
>> as long as the aggregate capacity in routing table size and bandwidth
>> is adequate.
>>
>> The downside is that not having the same information available
>> throughout an AS increases operational and/or protocol complexity.

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram