Re: RTX/FEC (Re: Statement from the IETF ART and SEC Area Directors regarding the "Trusted application, untrusted intermediary" use case)

On Thu, 29 Nov 2018 at 11.28, Randell Jesup <randell-ietf@jesup.org> wrote:

> On 11/29/2018 9:33 AM, Harald Alvestrand wrote:
>
> (My personal view is that RTX should be removed because it doesn't give
> enough benefit from the extra bits, and that FEC should limited to
> long-delay connections for the same reasons, so I can't bring myself to
> care enough to write requirements for it - but others might think
> differently, and have the measurements to support their position, which
> I don't.)
>
>
> On this side-note: I've never been strongly convinced of the utility of
> RTX (it has some utility, but doesn't seem to matter a lot in practice),
> which is why Mozilla deferred having any support for it so long.  FEC has
> more use, but wow can it eat bits, and if it doesn't you get a lot less
> benefit.  In long-latency very-lossy connections, and in no-return-channel
> or delayed/low-bw return channel it has some use.  Variable FEC has some
> utility (depending on latency, or maybe unequal protection (keyframes only
> for example), and using FEC for stuff like bandwidth probing makes some
> sense, perhaps.
>
> Both seem like somewhat edge/corner-case solutions in the modern network
> usage, except maybe the probing argument.  Even keyframes may be better
> handled with NACK/retransmit unless network latency is high.
>

We wrote a paper, I didn’t realize it’s now 10 years old in December. The
paper analyzed error resilience mechanism
1. NACK
2. RPS, reference picture selection
3. SSA, slice size adaptation
4. ULPFEC

Some of these mechanisms may only apply t H.264, and partly to the fact
that the H.264 was configured for using temporal scalability IPpPpP..
(details in the paper)

And the paper was my first and first step into the use of adapting error
resilience mechanisms for congestion control.

The figure 7 shows (what’s perhaps intuitive and has been stated before)
that NACKs are useful for low end to end delay and low loss rates.

FEC is more useful in higher delay and somewhat predictable burst loss
patterns. Read the paper, it’s been 10y so it needs to be relooked at
again. If someone has cycles to reinvestigate, I’m happy to mentor.

Regards,
Varun.

Evaluation of error resilience mechanisms for 3g conversational video
J Devadoss, V Singh, J Ott, C Liu, YK Wang, I Curcio
Multimedia, 2008. ISM 2008. Tenth IEEE International Symposium on, 378-383,
2008



-- 
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/