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

Dave Thaler <dthaler@windows.microsoft.com> Tue, 08 May 2007 20:20 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 1HlWAf-0000fv-MY; Tue, 08 May 2007 16:20:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWAd-0000fk-9L for ram@iab.org; Tue, 08 May 2007 16:20:27 -0400
Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWAb-0007mW-VA for ram@iab.org; Tue, 08 May 2007 16:20:27 -0400
Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 13:20:25 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 13:20:25 -0700
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 13:20:24 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RAM] The mapping problem: rendezvous points?
Date: Tue, 08 May 2007 13:19:57 -0700
Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAM] The mapping problem: rendezvous points?
Thread-Index: AceRrAFWFrX1N2rPSfeX3yGvx9klPQAAYTzg
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com>
From: Dave Thaler <dthaler@windows.microsoft.com>
To: Tony Li <tli@cisco.com>
X-OriginalArrivalTime: 08 May 2007 20:20:24.0780 (UTC) FILETIME=[4F84F8C0:01C791AE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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

> -----Original Message-----
> From: Tony Li [mailto:tli@cisco.com]
> Sent: Tuesday, May 08, 2007 1:03 PM
> To: Dave Thaler
> Cc: Iljitsch van Beijnum; ram@iab.org
> Subject: Re: [RAM] The mapping problem: rendezvous points?
> 
> 
> Dave,
> 
> On May 8, 2007, at 11:18 AM, Dave Thaler wrote:
> 
> > I disagree with the word "everything".  The two high level choices
> > are:
> >
> > 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).
> 
> 
> Thanks for the summary.  I think we should also point out that there
> are a variety of hybrids, where some parts of the mapping are pushed
> and some parts of the mapping remain to be pulled.
> 
> 
> > DHTs distributing log(N) information to each node are another type
of
> > PUSH, and don't have the scalability issues.
> 
> 
> I'd claim that that's a hybrid, where you push information to some
> locations, but since no system has a full mapping, you end up pulling
> the needed entries at some point.  I agree that it avoids the
> scalability problem and hope folks take careful note of this.
> [...]

I agree there are hybrid cases possible, but what I was saying is not a
hybrid at all.

In hybrid schemes it comes down to whether there is any case of "slow"
or not.  

For example, in one class of hybrid schemes:

PUSH is used to get log(N) information such that any packet can be
immedidately forwarded upon arrival, and PULL is used in parallel to
forwarding to obtain a more optimal destination for future traffic.
This one is not problematic.

PUSH is used to get some information, but there remain cases where
a packet can arrive and PULL must be used before the packet can be
forwarded (i.e. encapsulated) somewhere.  This one is problematic
for the same reason as PULL.

So as long as a hybrid is PUSH (not everything) with PULL _as an
optimization_, I claim it's better than where PULL is _a necessity_ and
PUSH is just an optimization.

-Dave


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