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

Lars Eggert <lars.eggert@nokia.com> Thu, 10 May 2007 00:44 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 1HlwlQ-0001TX-8W; Wed, 09 May 2007 20:44:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlwlP-0001TS-Gx for ram@iab.org; Wed, 09 May 2007 20:44:11 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlwlN-0000jq-UZ for ram@iab.org; Wed, 09 May 2007 20:44:11 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4A0i4qc001213; Thu, 10 May 2007 03:44:06 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300
Received: from [192.168.2.16] (daec-linuxvpn059168.americas.nokia.com [10.241.59.168]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4A0hwZu009142; Thu, 10 May 2007 03:43:59 +0300
In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@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> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <F2F9AE97-7599-42BB-A542-A4B33AC3FD18@virtualized.org> <F3A8A33D-614D-4E6F-9741-61FFBB42E40C@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <80973F3D-CFAB-443F-BB85-26033E39508C@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Wed, 09 May 2007 16:43:47 -0800
To: ext David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 May 2007 00:44:04.0503 (UTC) FILETIME=[4F38E270:01C7929C]
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="===============0259648697=="
Errors-To: ram-bounces@iab.org

On 2007-5-9, at 15:58, ext David Conrad wrote:
>>> I'll ask again:  how does this ARP thing work again?
>> First off, all the ARP implementations I know of queue the packet  
>> during the loopkup, i.e., no loss.
>
> That's what I thought, but folks have been saying that routers  
> don't queue anymore.

I'm only familiar with end-host ARP code.

>> Second, the duration of an ARP lookup vs. the end-to-end RTT is  
>> typically miniscule. This is not so with LISP-like schemes.
>
> Yes, but memory for queues (for edge device I/O queues) is much  
> cheaper than it was...

I'm not worried about memory at all.

Whether a packet is queued while an ARP lookup is performed won't  
noticeably affect the end-to-end RTT that TCP measures, i.e., it  
won't affect TCP's RTT sampling. When LISP queues a packet while it  
does its magic, that is likely to take more time, because it's not a  
purely local operation, and this delay may influence TCP's RTT  
sampling, causing inefficiencies.

(When LISP forwards packets along a path with higher stretch during  
the setup phase, rather than queuing them, that may cause other  
inefficiencies, which I described in my first reply.)

Lars


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