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

[Stefan Hakansson LK <[e-mail]>]

On 07/02/2012 11:51 PM, Randell Jesup wrote:
> On 7/2/2012 4:18 PM, Justin Uberti wrote:
>> As has been pointed out in this thread before, this discussion is not
>> about mandating the USE of retransmission in realtime scenarios.  It is
>> simply trying to decide whether retransmission should be required to be
>> present in the 'toolbox' of tools that WebRTC apps can expect to use,
>> primarily where the app developer and runtime developer are separate
>> (e.g. in a browser).
>
> Do you expect to expose this choice to the application? (and all the
> data needed to make the choice...)  Or have it be automatic?
>
>> Several people have pointed out scenarios and applications where
>> retransmission (of video, not audio) works very well. Our experience
>> matches this too. Typically we can locate a media gateway very close to
>> all participants, meaning that a lost packet between GW and user can be
>> detected and retransmitted fast enough to not be noticeable by the user.
>> These applications, if they do not have access to retransmission, will
>> be forced to use cruder methods of error recovery that are more
>> noticeable to users, among other unpleasant effects.
>
> Ok.  This says that it's preferable to implement it, and if you have one
> of the situations that works well, use it.  This sounds like a SHOULD to
> me, since other implementations (say an audio-only WebRTC<->PSTN
> gateway) may have little or no use for retransmission, or might reject
> it always.
>
>> Given that the implementation cost of retransmission is fairly
>> negligible (basically, a packet cache plus support for parsing NACK
>> messages), and that is really the only reason NOT to support this
>> functionality in the toolbox, I have a hard time understanding why we
>> would not want to make this a MUST implement for WebRTC.
>>
>> 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?

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

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.

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