Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED

Michael Welzl <michawe@ifi.uio.no> Thu, 28 June 2012 10:30 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBBD21F84B8 for <rtcweb@ietfa.amsl.com>; Thu, 28 Jun 2012 03:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTBUzAsC59Ay for <rtcweb@ietfa.amsl.com>; Thu, 28 Jun 2012 03:30:13 -0700 (PDT)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id D44F321F8470 for <rtcweb@ietf.org>; Thu, 28 Jun 2012 03:30:09 -0700 (PDT)
Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1SkBzE-0004Xn-7k for rtcweb@ietf.org; Thu, 28 Jun 2012 12:30:08 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtp (Exim 4.76) (envelope-from <michawe@ifi.uio.no>) id 1SkBzD-0003wz-Hr for rtcweb@ietf.org; Thu, 28 Jun 2012 12:30:08 +0200
Message-ID: <4FEC322E.1090908@ifi.uio.no>
Date: Thu, 28 Jun 2012 12:30:06 +0200
From: Michael Welzl <michawe@ifi.uio.no>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4FEAB80A.7040207@ericsson.com> <4FEC0C73.4030709@ericsson.com>
In-Reply-To: <4FEC0C73.4030709@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 21017 max rcpts/h 58 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 7AD85A7ED08DB6C025AA14E0B6B1E917B611BEE0
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 8816 max/h 20 blacklist 0 greylist 0 ratelimit 0
Subject: Re: [rtcweb] RTP Usage: Is RTP Retransmission REQUIRED or RECOMMENDED
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 10:30:13 -0000

Hi,

I second that.

Here's one more reason: I believe that it should also be possible for a 
receiver to make use of retransmitted I-macroblocks from old frames that 
have been shown long ago. Future MBs may still depend on them, and so 
their quality could be improved with that information.

This is a quite theoretical idea - I don't have any proof that this 
would work, and don't know of research that has that proof (but I 
suspect one can find some, if one looks). It's just one more reason why 
retransmissions could turn out to be valuable.

Cheers,
Michael


On 6/28/12 9:49 AM, Magnus Westerlund wrote:
> Hi,
>
> As Individual I like to state my position.
>
> We have a video conference system developed by my colleagues used
> internally at Ericsson that uses RTP Retransmission for video, not for
> audio with great success. This is implemented such that we actually
> allow the video to fall behind the audio when packet loss and
> retransmission is not able to repair in a timely enough fashion. The
> benefit is minimal overhead and still no loss induced degradations in
> the video. Yes, we get degradation in form of frame display jittering
> and short freezes. But those events that are truly visible are rare over
> wired networks.
>
> I am personally convinced that RTP Retransmission is great tool in the
> toolbox when it comes to improve media quality in many use cases. Yes
> there are scenarios where RTP retransmission is less efficient. Long
> RTTs (over 200-400 ms) is the primary source of degradations. Compared
> to FEC it so much more efficient from bandwidth consumption perspective.
>
> I also think it is important that we have some mandatory to implement
> tool for making the transport more robust now that we have a consensus
> that we are not going for a FEC solution in the initial specification.
>
> Thus my personal position is that RTP Retransmission should be REQUIRED
> to implement.
>
> Cheers
>
> Magnus
>
>
> On 2012-06-27 09:36, Magnus Westerlund wrote:
>> WG,
>>
>> We had a discussion at the interim if RTP Retransmission is to be
>> considered REQUIRED or RECOMMENDED to implement. I would like to see if
>> we can first have some discussion on this topic before moving on to see
>> if we can get a consensus here on the mailing list.
>>
>> Please provide your views on this topic.
>>
>> Cheers
>>
>> Magnus Westerlund
>> (As Chair and document editor)
>>
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>