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

David Conrad <drc@virtualized.org> Wed, 09 May 2007 18:09 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 1Hlqb3-0003gF-5J; Wed, 09 May 2007 14:09:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlqb2-0003gA-7S for ram@iab.org; Wed, 09 May 2007 14:09:04 -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 1Hlqb0-0006mt-QP for ram@iab.org; Wed, 09 May 2007 14:09:04 -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 l49HphHT070227; Wed, 9 May 2007 10:51:43 -0700 (PDT) (envelope-from drc@virtualized.org)
In-Reply-To: <p06240602c267b7bdf733@[76.102.225.135]>
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> <p06240602c267b7bdf733@[76.102.225.135]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <380DB505-2581-4E48-B413-37BB6AB6272F@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 11:07:28 -0700
To: Ted Hardie <hardie@qualcomm.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
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

Ted,

On May 9, 2007, at 10:47 AM, Ted Hardie wrote:
> 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.

And how do those codec negotiations/ICE behave in the face of network  
congestion today?

> 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?

Pointers to source code would be nice.

I guess where I'm seeing a disconnect is in the fact that the  
Internet today is best effort, has congestion events, asymmetric  
routing and non-deterministic performance patterns.  If an  
application works today, I'm having trouble understanding how the  
introduction of additional O(10-100ms) latencies in the event of a  
cache miss (which will likely only occur at the first packet in a  
packet train) is going to have significant impact.  In those odd  
cases that there is an impact, how much work would it be to modify  
the application operation to be more tolerant of network delays?

Clearly, some believe that pull simply won't work.  I'm trying to  
understand why.  To be honest, it feels a bit like arguments I used  
to hear from Bellheads explaining why real production data  
communications could never work on datagram based networks...

Rgds,
-drc


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