IETF Logo Mail Archive

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

Dave Thaler <dthaler@windows.microsoft.com> Tue, 08 May 2007 23:39 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 1HlZHe-0000s2-K2; Tue, 08 May 2007 19:39:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZHd-0000rs-E8 for ram@iab.org; Tue, 08 May 2007 19:39:53 -0400
Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZHc-0005aL-4R for ram@iab.org; Tue, 08 May 2007 19:39:53 -0400
Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) 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 16:39:51 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 16:39:49 -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 16:39:49 -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 16:39:43 -0700
Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA772@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAM] The mapping problem: rendezvous points?
Thread-Index: AceRyTZbySeF1vW/T1icgcX8nalArQAAGMtw
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> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com>
From: Dave Thaler <dthaler@windows.microsoft.com>
To: Spencer Dawkins <spencer@mcsr-labs.org>, David Conrad <drc@virtualized.org>
X-OriginalArrivalTime: 08 May 2007 23:39:49.0251 (UTC) FILETIME=[2AE65D30:01C791CA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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

Spencer Dawkins [mailto:spencer@mcsr-labs.org]
> > 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.
> 
> Dave,
> 
> I've heard variations on the "deterministic loss" thing in several
places
> recently, and I don't understand all the context, but people have
usually
> been talking about deterministic loss AT THE BEGINNING of a TCP
connection,
> or AT THE BEGINNING of an MPEG stream where you're losing complete
images
> and then all you receive for a while is deltas from the image you
lost.
> 
> Are you talking about more than this?

That's mainly what I'm talking about.  The generalization is that
deterministic loss in response to any application-initiated request
is bad... e.g. deterministic loss at the beginning, or on every send,
or at the end (which may leave state hanging on the other end for long
periods of time until it expires).  However, I think the main case I've
seen people actually proposing is deterministic loss at the beginning.

(And I'm using the term "deterministic" loosely to mean "non-negligible
chance".  And "random" to mean "negligible chance".)

-Dave

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

v2.23.0 | Report a Bug | By Email