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

Marshall Eubanks <tme@multicasttech.com> Wed, 09 May 2007 10:15 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 1HljD8-0007QT-0P; Wed, 09 May 2007 06:15:54 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HljD6-0007QF-Eg for ram@iab.org; Wed, 09 May 2007 06:15:52 -0400
Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HljD4-0000yp-4U for ram@iab.org; Wed, 09 May 2007 06:15:52 -0400
Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6582109; Wed, 09 May 2007 06:15:43 -0400
In-Reply-To: <p0624061bc2670339db15@[129.46.226.38]>
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> <p0624061bc2670339db15@[129.46.226.38]>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <D4BB3F0E-7097-438E-B0C9-7AFB19E371AF@multicasttech.com>
Content-Transfer-Encoding: 7bit
From: Marshall Eubanks <tme@multicasttech.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Wed, 09 May 2007 06:15:37 -0400
To: Ted Hardie <hardie@qualcomm.com>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

On May 9, 2007, at 12:52 AM, Ted Hardie wrote:

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

That it correct. Note that the application could decide that the  
session was not possible and drop it entirely.
(Say, if there was only 1 bit rate on offer.)

If the interruption is as long as a couple of seconds, that is quite  
possible.

> 				regards,
> 					Ted
>

Regards
Marshall

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


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