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

On 10-sep-2007, at 4:16, Noel Chiappa wrote:

>> If nothing much is happening and caches are empty, and a host then
>> starts a session towards some remote destination, in a pull model,  
>> the
>> encapsulating device must first look up a mapping so it can  
>> perform the
>> required encapsulation. So the first packet must be dropped.

> Well, is that latter really necessary?

"Routers are not in the storage business."

But if they were, there would be a limit to what they can store, and  
I think it's likely this limit is smaller than the maximum number of  
packets that the router can receive in the maximum time it can take  
until the mapping process completes.

So I'd say that drops will happen, even if some storage is added as  
an optimization.

>> If there is some place packets for destinations that aren't mapped  
>> yet
>> can be sent to so they arrive anyway, even if this path is slower,  
>> this
>> takes a lot of pressure off of the encapsulation devices,

> Interesting idea. Let me ponder that...

>> The issue of determining rendezvous locations .. is simple enough:  
>> have
>> each rendezvous point handle a very long prefix, such as 96/6.

> How about piggybacking the user's data packet on the request for the
> EID->RLOC binding?

Wouldn't that be a specific implementation of the general idea of  
sending packets for which there is no mapping to a location that  
knows how to deliver them?

> When the request gets to whereever that binding is
> available, it's sent on to the ETR, while the mapping is sent back  
> to the
> requestor? That avoids all the extra mechanism/configuration of  
> rendezvous
> points.

It's a tradeoff between the complexity of having an additional system  
or the complexity of having multiple functions in one system. I'd say  
that it would be good to design things such that it's possible to do  
it in separate rendezvous points and then let the implementers figure  
out whether they want to do it that way or not.

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