Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt

Steve Underwood <steveu@coppice.org> Tue, 28 November 2006 16:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5oM-00014W-9e; Tue, 28 Nov 2006 11:27:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5oL-00014B-9s for avt@ietf.org; Tue, 28 Nov 2006 11:27:57 -0500
Received: from cwb.pacific.net.hk ([202.14.67.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5oI-0005oK-K2 for avt@ietf.org; Tue, 28 Nov 2006 11:27:57 -0500
Received: from [192.168.2.50] (40.168.17.210.dyn.pacific.net.hk [210.17.168.40]) by cwb.pacific.net.hk with ESMTP id kASGRjiv027277 for <avt@ietf.org>; Wed, 29 Nov 2006 00:27:45 +0800
Message-ID: <456C6381.5000002@coppice.org>
Date: Wed, 29 Nov 2006 00:27:45 +0800
From: Steve Underwood <steveu@coppice.org>
User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avt@ietf.org
Subject: Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt
References: <144ED8561CE90C41A3E5908EDECE315C04136BF2@IsrExch01.israel.polycom.com> <456C5B6C.3010407@hyervision.com>
In-Reply-To: <456C5B6C.3010407@hyervision.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Adam Li wrote:

>Hi Roni, Steve,
>
>Thanks for the comments.
>
>(1) About the effectiveness of ULP
>This issue was the first thing that we presented when we proposed ULP
>extension to RFC 2733 (which evolved to the current draft). In our
>presentation in IETF-50, the rate-distortion performance of ULP is
>throughly tested with H.263 at various loss rates. The gain is from
>around 1/4 dB at 1% loss to around 1 dB at 5% loss. Please check the
>detailed graphs in that presentation. Hope that answered your concern there.
>
>(2) About the effectiveness of XOR
>As also pointed out by Andrea Lorenzo in an earlier reply, the XOR can
>be quite effective recover from loss, and more importantly is extremely
>simple to implement. The fact that we now have RFC 2733 implemented in
>many endpoints is a good validation that XOR can be used effectively.
>The current draft being an update to RFC 2733, I don't feel we need to
>re-justify that fact again, right?
>
>Regards,
>
>Adam
>  
>
Could you point to some end points actually using RFC2733? I've been 
trying to find some real world implementations of RFC2733, and I've come 
up blank. I noticed someone recently asked on this list if anyone had 
implemented RFC2733, and there seemed to be no reply.

I am currently interested in implementing RFC2733 for T.38 over RTP. 
However, the results so far make it look like a waste of time. The only 
way to get a meaningful boost in packet loss tolerance over simple 
redundancy causes too much latency. If I didn't care much about latency 
I wouldn't be using RTP in the first place. For the more commonly used 
UDPTL transport for T.38 I have implemented both the redundancy scheme 
which is akin to RFC2198 and the FEC scheme akin to simple XOR'ing with 
RFC2733. In the real world it seems everyone uses only the redundancy 
option, and important packets are sent multiple times.

Regards,
Steve

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt