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

Lars Eggert <lars.eggert@nokia.com> Wed, 09 May 2007 22:05 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluHm-0001jH-W7; Wed, 09 May 2007 18:05:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluHl-0001fL-Os for ram@iab.org; Wed, 09 May 2007 18:05:25 -0400
Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HluHk-0002Xv-60 for ram@iab.org; Wed, 09 May 2007 18:05:25 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49M59Xg018059; Thu, 10 May 2007 01:05:20 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300
Received: from [192.168.2.16] (essapo-nirac253205.europe.nokia.com [10.162.253.205]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49M5DQ7010455; Thu, 10 May 2007 01:05:15 +0300
In-Reply-To: <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org>
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Wed, 09 May 2007 14:05:10 -0800
To: ext David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 09 May 2007 22:05:19.0987 (UTC) FILETIME=[222B1430:01C79286]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1785506485=="
Errors-To: ram-bounces@iab.org

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


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