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

David Conrad <drc@virtualized.org> Tue, 08 May 2007 23:06 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 1HlYlD-00063h-1j; Tue, 08 May 2007 19:06:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYlC-00063Q-Kq for ram@iab.org; Tue, 08 May 2007 19:06:22 -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 1HlYe3-0000Kj-TF for ram@iab.org; Tue, 08 May 2007 18:59:01 -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 l48MhCHT068082; Tue, 8 May 2007 15:43:12 -0700 (PDT) (envelope-from drc@virtualized.org)
In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@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> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@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: <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org>
Content-Transfer-Encoding: 7bit
From: David Conrad <drc@virtualized.org>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Tue, 08 May 2007 15:58:55 -0700
To: Dave Thaler <dthaler@windows.microsoft.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
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

Dave,

On May 8, 2007, at 1:27 PM, Dave Thaler wrote:
> Applications generally work fine with random loss.
> They work less well with _deterministic_ loss.

I would've thought the opposite would be true.

> Some common application models that are adversely affected by PULL:
>
> 1) Client resolves a name to a list of addresses, and tries each one
> (with some timeout since there's no guarantee of response) until a
> connection succeeds.
> ...
> 2) Client resolves a name to a list of addresses, and tries each
> one in parallel and chooses the first one to succeed.
> ...

Since both of these are already relying on a pull mechanism at the  
initiation of a transaction, it isn't clear to me how they would be  
significantly more adversely affected by using a pull-based mapping  
mechanism.

> 3) Server responds to a simple client request via an asymmetric path.
> No DNS occurs here, and the response goes via a router not involved
> in the client-to-server direction.

This case would indeed cause an increase in latency.

> The above are just examples of common application classes which show
> why I personally consider PULL schemes to be a non-starter.

I was wondering if you had concrete examples of existing applications  
that would fail with an increase in initial packet latency.

Rgds,
-drc


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