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

Ted Hardie <hardie@qualcomm.com> Wed, 09 May 2007 17:47 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 1HlqGc-000071-Gq; Wed, 09 May 2007 13:47:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqGb-00006g-9P for ram@iab.org; Wed, 09 May 2007 13:47:57 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlqGZ-0003x7-U1 for ram@iab.org; Wed, 09 May 2007 13:47:57 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l49Hli0N015891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 10:47:44 -0700
Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l49HlacO013314; Wed, 9 May 2007 10:47:42 -0700
Mime-Version: 1.0
Message-Id: <p06240602c267b7bdf733@[76.102.225.135]>
In-Reply-To: <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org>
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org>
Date: Wed, 09 May 2007 10:47:34 -0700
To: David Conrad <drc@virtualized.org>, Eliot Lear <lear@cisco.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
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

At 9:39 AM -0700 5/9/07, David Conrad wrote:
>Eliot,
>
>On May 9, 2007, at 9:13 AM, Eliot Lear wrote:
>>I feel like we've had this argument before.
>
>Yep.  You and others keep asserting that a pull-based mapping distribution model is a "non-starter" because it "won't work".  I've been trying to get from folks _concrete_ examples of applications that "won't work" in the face of increased latencies on the order of 10s or 100s of milliseconds after a cache miss.  In response I get vague handwaving about voice or video (I know from personal experience that UDP-based NFS works fine in the face of an initial packet delay of 10s of milliseconds) or descriptions about classes of applications that would appear to be degenerate cases and asymmetric routing that would likely have unpredictable performance characteristics with pull or push.
>
>GIven the lack of data, it would seem we've descended to the realm of religion, so I'll give it a rest.

Sorry, but I misunderstood you to be asking for what class of applications have
this problem, and my reply was intended to answer that:  those which do codec
negotiation based on observed rate.  Another class is those that use race conditions
to select flow endpoints (e.g. anything that will use ICE).  Not too many things
use ICE yet (still not standardized), but there are plenty in the former category.
Are you looking for something that has source code available, so you can see
what changes it would take to adjust the paradigm, or ubiquity, or what?

				Ted

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