IETF Logo Mail Archive

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

Ted Hardie <hardie@qualcomm.com> Wed, 09 May 2007 04:52 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 1HleAI-0007WD-GF; Wed, 09 May 2007 00:52:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HleAH-0007W8-Gy for ram@iab.org; Wed, 09 May 2007 00:52:37 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HleAG-0004Je-6n for ram@iab.org; Wed, 09 May 2007 00:52:37 -0400
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l494qYto025748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 21:52:34 -0700
Received: from [129.46.226.38] (vpn-10-50-0-146.qualcomm.com [10.50.0.146]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l494qU1b022304; Tue, 8 May 2007 21:52:32 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0624061bc2670339db15@[129.46.226.38]>
In-Reply-To: <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com>
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> <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com>
Date: Tue, 08 May 2007 21:52:29 -0700
To: Spencer Dawkins <spencer@mcsr-labs.org>, David Conrad <drc@virtualized.org>, Dave Thaler <dthaler@windows.microsoft.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: 79899194edc4f33a41f49410777972f8
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 6:30 PM -0500 5/8/07, Spencer Dawkins wrote:
>>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.
>
>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.

It's my understanding that some applications facing the media stream aspect of this
will negotiate the codec or codec parameters to degrade the quality in the face of
this.  This degradation can last for the duration of the stream, or renegotiation
can take place but result in slow restoration of quality.

				regards,
					Ted

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

v2.23.0 | Report a Bug | By Email