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

[Randell Jesup <[e-mail]>]

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.

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]