IETF Logo Mail Archive

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

David Conrad <drc@virtualized.org> Wed, 09 May 2007 22:21 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 1HluX3-0000UW-UQ; Wed, 09 May 2007 18:21:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluX2-0000UR-V1 for ram@iab.org; Wed, 09 May 2007 18:21:12 -0400
Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HluX1-0005uU-JR for ram@iab.org; Wed, 09 May 2007 18:21:12 -0400
Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49M5AHT070687; Wed, 9 May 2007 15:05:11 -0700 (PDT) (envelope-from drc@virtualized.org)
In-Reply-To: <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.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>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F2F9AE97-7599-42BB-A542-A4B33AC3FD18@virtualized.org>
Content-Transfer-Encoding: 7bit
From: David Conrad <drc@virtualized.org>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Wed, 09 May 2007 15:20:56 -0700
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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>
Errors-To: ram-bounces@iab.org

Lars,

On May 9, 2007, at 3:05 PM, Lars Eggert wrote:
> 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.

Yes, but you left out the part about those protocols having  
mechanisms to detect and recover from connectivity degradation (e.g.,  
slow start).

However, this is largely irrelevant as in any rational pull-based  
mapping mechanism, the mapping information would be cached for all  
but the initial packet.

> More specifically, with LISP-like proposals and TCP, potential  
> issues are things like a 3-second timeout if the first (SYN) packet  
> is dropped.

I'll ask again:  how does this ARP thing work again?

Actually, I'll ask a different question:

People have been talking about having a push based mapping  
mechanism.  They have also been talking about having host-level  
granularity.  How is this going to work?  Are people imagining a  
flood protocol that propagates host-level mappings to every host on  
the Internet?

Thanks,
-drc


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

v2.23.0 | Report a Bug | By Email