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

[Lars Eggert <lars.eggert at nokia.com>]

On 2007-5-9, at 8:03, ext David Conrad wrote:
> My point is that applications already must cope with the fact that  
> the Internet is "best effort" and stuff happens to cause packet  
> loss or delay.  A pull-based mapping redistribution model implies  
> an increased amount of latency on cache misses (most likely on the  
> order of tens to hundreds of milliseconds, not seconds).  Internet  
> applications that I know of already must deal with variable  
> latencies of these orders of magnitude and I was asking for  
> pointers to applications that couldn't.

Don't forget that pretty much all our transport protocols work by  
gathering information about the transmission path (RTT, bandwidth,  
etc.) by running statistics over the packets they send. The  
assumption is that the path you'll send over in the near future will  
sort-of have similar characteristics to the one you have been sending  
over in the recent past. Anything that changes this assumption can  
potentially have negative impacts on the operation of our existing  
transport protocols.

(A well-documented example is the bad interactions between MobileIP  
and TCP across mobility events.)

More specifically, with LISP-like proposals and TCP, potential issues  
are things like a 3-second timeout if the first (SYN) packet is  
dropped. If the first packets take a different path, the issue is  
that the RTT and congestion window estimates won't describe  
conditions on the "final" path, which causes either inefficiencies or  
losses and then timeouts.

Lars

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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