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

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Fri, 06 July 2012 07:08 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 50CEF21F8622 for <rtcweb@ietfa.amsl.com>; Fri, 6 Jul 2012 00:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.935
X-Spam-Level:
X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 MoPjA+fMviAt for <rtcweb@ietfa.amsl.com>; Fri, 6 Jul 2012 00:08:49 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F085321F86AA for <rtcweb@ietf.org>; Fri, 6 Jul 2012 00:08:48 -0700 (PDT)
X-AuditID: c1b4fb30-b7fb46d0000064f2-58-4ff68f0fb20f
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.90.25842.F0F86FF4; Fri, 6 Jul 2012 09:09:03 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Fri, 6 Jul 2012 09:09:02 +0200
Message-ID: <4FF68F0B.6090905@ericsson.com>
Date: Fri, 06 Jul 2012 09:08:59 +0200
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4FEAB80A.7040207@ericsson.com> <4E5389B4-F54C-4060-952E-8319A801FDC3@iii.ca> <4FED4E81.7000607@ericsson.com> <B7F8286E-BDB0-4033-991C-A54A0A1227EB@iii.ca> <A8D45DD6-4E82-413F-8978-C6A80B2806DA@edvina.net> <CAOJ7v-1SwvqDrzOGGSwFjkmnqPmF8PVvbOoGrtbtx6qk2T_R-w@mail.gmail.com> <4FF217DD.1060607@jesup.org> <4FF451C7.5080804@ericsson.com> <4FF521DF.1090202@jesup.org>
In-Reply-To: <4FF521DF.1090202@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+JvrS5//zd/g3ULVSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsV9PxkL+tQqJuxez9TAeE6ui5GTQ0LAROLcv5vsELaYxIV7 69m6GLk4hAROMUpcu7GYFSQhJLCMUeLJfCkQm1dAW2JNUw9YnEVAReLd1RtMIDabgI3E2u4p QDYHh6hAmMT0newQ5YISJ2c+YQGxRQSEJba+6gUrERbwk5jfEAZiCgn8YJKYVgxSwSmgKbH7 6zQ2EJtZwFbiwpzrLBC2vMT2t3OYIY7RlXj3+h7rBEaBWUgWzELSMgtJywJG5lWMwrmJmTnp 5eZ6qUWZycXF+Xl6xambGIGBd3DLb4MdjJvuix1ilOZgURLn1VPd7y8kkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBUe7rz/1yLydZ335sWLpPf0+4sNRdxcW/V67n0n/wUKPw0smpk+bwNG5V 5fuRZpz0+G/YsUweiyffF/Kkdj0pNuucFbdp9dTUOz4Ch5UtGVjzfupdO7Thei/H7Flz07UO Lkk6JMmZsn+Gez6vhYBzkbPrfjdP2Qv7lwkEzPuRUzbR/ka74vYXVUosxRmJhlrMRcWJAPx3 cOgKAgAA
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: Fri, 06 Jul 2012 07:08:50 -0000

On 07/05/2012 07:10 AM, Randell Jesup wrote:
> On 7/4/2012 10:23 AM, Stefan Hakansson LK wrote:
>> On 07/02/2012 11:51 PM, Randell Jesup wrote:
>>>
>>>> Again, this is about making _support_ for retransmission a requirement,
>>>> not _use_.
>>>
>>>
>>> If you don't mandate use, what does mandating "support" buy you?  An
>>> implementation (see above about PSTN gateways) might always decline to
>>> use retransmission, so what does MUST (REQUIRE) buy you?  I say SHOULD
>>> (RECOMMEND), with a statement that it's strongly recommended it be
>>> supported if video is supported, especially for non-single-purpose
>>> devices (i.e. browsers).
>>>
>>> In either case, you need to think about who decides to use re-xmit or
>>> not, what influences that, and if the app has visibility into this.
>>> Someone could as an rtx-time=0 to the SDP.  Or not include one, but
>>> never actually retransmit a packet regardless of NACKs - it could just
>>> repair via IDR (or other means).
>>>
>>> So here's a real problem related to retransmission: since the request is
>>> not specific and negotiated (it's normally a generic NACK), the receiver
>>> who sent the NACK has no idea if it will get a retransmission, an IDR
>>> (or IDR slice), another form of repair (pframe/slice against
>>> known-decoded frame - rpsi/etc), or nothing at all (NACK lost). So, it
>>> doesn't know if it should freeze the video or play with errors. It has
>>> to decide if it *thinks* the sender will use retransmission, or if it
>>> doesn't, does the receiver want to freeze video until an IDR or other
>>> repair is done, which might be a while.
>>
>> Isn't retransmission negotiated using "rtx", "atp" and so on?
>
> Support for it is.  However, negotiating support for it doesn't solve
> the problem of not knowing how the sender will respond to a NACK (or
> SLI/RPSI/etc).  Generally, the sender has to make the decision, but the
> receiver has to guess.
>
>>
>> One way of removing the uncertainty would be to require that all
>> browsers support RTP retransmission: This way, any RTP endpoint
>> sending a NACK to a browser would know that that packet would be
>> retransmitted (given that congestion does not prohibit, or NACK packet
>> is lost etc.).
>
> Um, no.  Just because both sides support retransmission does not mean
> that a NACK will generate a retransmission.  Retransmission only makes
> sense in some instances, and there's no guarantee that retransmission
> will be possible (for example, the requested packet might have timed out
> and been thrown away).

All I was trying to say was that mandating support for retransmission 
would remove one uncertainty. But I agree that there are situations when 
there still would be no retransmission (and the receiver would not know 
why).

But I guess you're also saying that mandating it would not be helpful 
since the sender decides, and could in principle have support for 
retransmission, but being set up/implemented/tuned in such a way that it 
(almost) never retransmits. I didn't think about that; and I don't know 
how big that risk is.

>
>>
>> If we have this in place, I'm confident that implementors will quickly
>> develop strategies on how and when to _use_ retransmission in the best
>> way. There has already been input made on its usefulness.
>
> Sure, and they will anyways.  RECOMMENDED or REQUIRED, it really doesn't
> matter to the implementation.  For that matter, even if REQUIRED there's
> nothing that says it has to be offered or accepted.  Even if that were
> mandated, the implementation could accept but with a 0-length rtx-time.
> So it's really unclear what REQUIRED buys you that RECOMMENDED doesn't.
>
>>
>> Maybe the problem with legacy not always supporting retransmission is
>> not that big. First of all, legacy is to a large extent audio only
>> (e.g. PSTN), and no one is arguing for retransmission there. Secondly,
>> I fail to see that this situation would be improved in any way if
>> browsers are only recommended (and not required) to support RTP
>> retransmission.
>>
>> So I think we should require rtcweb capable browsers to support RTP
>> retransmission.
>>
>>>
>>> We also need to think about when a receiver should use SLI or RPSI.  PLI
>>> can also be used and should be if the other options don't negotiate (so
>>> it's important to offer it).  Certainly it's more work to keep track of
>>> the contents of each packet (slices, etc), especially in things like
>>> H.264 NALU aggregation packets, than it is to just respond to an SLI.
>>>
>>> That said, my previous systems just used NACK and let the sender decide
>>> the correct repair, but I wasn't leveraging slices and wasn't using
>>> retransmission, so there was only minor complexity (looking at possible
>>> reference frames).
>
>