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

Lars Eggert <lars.eggert@nokia.com> Fri, 11 May 2007 01:07 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 1HmJbk-0006o9-CH; Thu, 10 May 2007 21:07:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJbj-0006o4-Hk for ram@iab.org; Thu, 10 May 2007 21:07:43 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmJbh-0001qC-V8 for ram@iab.org; Thu, 10 May 2007 21:07:43 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B17apN017919; Fri, 11 May 2007 04:07:39 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 04:07:37 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 04:07:36 +0300
Received: from [192.168.2.16] (essapo-nirac25340.europe.nokia.com [10.162.253.40]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B17VvT028008; Fri, 11 May 2007 04:07:32 +0300
In-Reply-To: <213401c79342$9339ecc0$6601a8c0@china.huawei.com>
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> <FD31231D-A190-41CB-AC4F-FB7871D7E695@cisco.com> <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> <5666C4B7-BCD4-476F-BC14-C2517EBEEF89@cisco.com> <213401c79342$9339ecc0$6601a8c0@china.huawei.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
X-Priority: 3
Message-Id: <2AEC9783-B009-405F-92D7-053080DEEB0D@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Thu, 10 May 2007 17:07:29 -0800
To: ext Spencer Dawkins <spencer@mcsr-labs.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 11 May 2007 01:07:37.0176 (UTC) FILETIME=[C3A76D80:01C79368]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
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="===============0799631654=="
Errors-To: ram-bounces@iab.org

On 2007-5-10, at 12:34, ext Spencer Dawkins wrote:
> I may be misunderstanding Lars, but I understood his point to be  
> that, unless the host is opening two connections back-to-back,  
> there is no ARP cache miss/queuing going on, and you don't normally  
> lose the first packet of a TCP connection ("3 second timeout"),  
> unless you're really seeing congestion (which is where you'd need  
> to wait for a chile, anyway).
>
> I understood his concern to be making sure we don't move from a  
> network where we see 20-200 ms ARP cache timeout/queuing to a  
> network where we see a 3-second timeout at the beginning of every  
> TCP connection. These would not be packet drops that have gone  
> unseen for decades.

Yup, I think we're on the same page here.

A very high-level summary of my concerns is that pull schemes can  
introduce variabilities (losses and/or delays) that can influence the  
operation of the end-to-end control loop that underlies most  
transport-level protocols. There is at least a potential for bad  
interactions.

We ran into this same issue with MobileIP, whose extensions to layer  
3 change the end-to-end path when handovers happen in a way that can  
make transport performance suck.

It would be very good to learn from this experience and make sure  
that we look into these issues during the design of new layer-3  
extensions - be it LISP or something else.

Lars


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