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

[Randell Jesup <[e-mail]>]

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

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


-- 
Randell Jesup
[e-mail]