IETF Logo Mail Archive

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

Dino Farinacci <dino@cisco.com> Tue, 08 May 2007 19: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 1HlVbn-00004u-Bq; Tue, 08 May 2007 15:44:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVbm-0008WV-Pw for ram@iab.org; Tue, 08 May 2007 15:44:26 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVbl-0007oz-Fj for ram@iab.org; Tue, 08 May 2007 15:44:26 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 May 2007 12:44:25 -0700
X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="146135086:sNHT43267572"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l48JiOti007195; Tue, 8 May 2007 12:44:24 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l48JiM0f005757; Tue, 8 May 2007 19:44:22 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 12:44:18 -0700
Received: from [192.168.0.4] ([10.21.100.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 12:44:17 -0700
In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <dino@cisco.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Tue, 8 May 2007 12:44:21 -0700
To: Dave Thaler <dthaler@windows.microsoft.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 May 2007 19:44:17.0876 (UTC) FILETIME=[43F1A940:01C791A9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1047; t=1178653464; x=1179517464; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=Aclg2a8AzWd8bO/5QaPP8HevUfI68O3KAgFYjm6XWDk=; b=d54/842VE1JNDMTxOwX6o+raVEgTO13pajbzQaVZhRUztiuTKiI13IRKZxw1dRKoFdRbMrus gc5Cs50B3Ro+UY3TzoaaA2TdrWqAbwG9ygkizfgR2XKqDoPn6NqG6+UP;
Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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

> PULL: work on-demand (which results in deterministic loss and hence
> adversely affects applications) and cache the result for some time
>
> PUSH: learn enough information (which may or may not be everything)
> ahead of time so that one has enough information to immediately  
> forward
> a packet when it arrives.  It would be desirable to learn log(N)
> information (and everyone may not learn the same information).
>
> Flooding everything is a type of PUSH, and has scalability issues.
> DHTs distributing log(N) information to each node are another type of
> PUSH, and don't have the scalability issues.
>
> Rendezvous points as you suggest below are another type of PUSH, where
> the non-rendezvous points have a small amount of information, but if I
> understand you correctly, the RPs still have the same scalability  
> issues
> as flooding everything.

For the last few months I have been sporting a new saying, inspired  
by our esteemed Yakov:

"Pull doesn't scale, Push doesn't scale, pick one".  ;-)

Dino


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

v2.8.7 | Report a Bug | By Email