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

[sorry, replying to an even older message... but I think this is  
important]

On 9-mei-2007, at 20:07, David Conrad wrote:

> If an application works today, I'm having trouble understanding how  
> the introduction of additional O(10-100ms) latencies in the event  
> of a cache miss (which will likely only occur at the first packet  
> in a packet train) is going to have significant impact.  In those  
> odd cases that there is an impact, how much work would it be to  
> modify the application operation to be more tolerant of network  
> delays?

I'm assuming an encapsulation device close to the source host that  
serves more than a single host, and maybe even a great number of hosts.

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. At the start of a session, that would be the first TCP SYN  
(or equivalent packet for other transport protocols). At this point,  
it doesn't matter all that much how fast the mapping information  
becomes available, because the application has to wait for a  
retransmission of the first packet. Obviously it doesn't help if the  
mapping system is so slow that the second packet is also dropped. But  
I think 10 - 100 ms is extremely optimistic, DNS is about an order of  
magnitude slower than that in practice and it takes ~ 350 ms round  
trip across the world.

So the difference here is that unlike with the DNS, where you can  
proceed as soon as there is an answer, you have to time out here, and  
both doing that too fast and too slow increases latency.

But that's only when the sky is blue and the sun is shining. When an  
encapsulation device suddenly gets a lot of traffic that has been  
going for a while, so it's happening at high speeds, but it somehow  
doesn't have any mapping state (mapping state timed out, rerouting  
between encapsulation devices, maybe even a reboot), very many  
packets will be lost while a mapping lookup is done. Also, if a large  
number of flows require mapping requests, it's entirely possible that  
these must be rate limited, increasing delays even further.

I guess it would be possible for the encapsulation device to send a  
message back to the source host that indicates that the packet was  
dropped so it should be retransmitted. I'm guessing TCP will do that  
for ICMP "packet too big" messages today.

However, I would prefer "initial non-optimizedness" over "initial  
loss". 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, making the downsides of pull and caching less problematic:  
mapping requests can be done at the rate that best suit the  
encapsulation device rather than as fast as possible to avoid  
application impact.

I suppose there are some applications that will try to judge network  
characteristics based on the first few packets, and in such a  
situation, they would come to unnecessarily conservative conclusions.  
However, this could be addressed by changing these applications  
rather than restricting the internet architecture.

The issue of determining rendezvous locations that Marshall brought  
up is simple enough: have each rendezvous point handle a very long  
prefix, such as 96.0.0.0/6. This of course sucks if you have 97.0.0.1  
and you're in South Africa while the relevant rendezvous point for  
96.0.0.0/6 is in Japan, but since the detour only happens for the  
first few packets this shouldn't be a huge issue.

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