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

On 11/29/2018 9:33 AM, Harald Alvestrand wrote:
> Den 29.11.2018 09:52, skrev Sergio Garcia Murillo:
>> Also, taking the keying issue aside, it is taken for granted that the
>> lower layer security exists and that we will use PERC for it, when
>> perc-double has huge impact on webrtc as it requires to modify all
>> stacks so the RTX+FEC processing is done AFTER the encryption (and not
>> before as in 1.0). As we will not be likely want to break compatibility
>> with 1.0 and non-perc endpoints we will still have to support current
>> processing order additionally.
> What's being proposed in the consensus call is the adoption of the
> requirements, not the adoption of a mechanism.
>
> As chair, I will strongly push back against people who claim that we
> have to write the requirements in such a way that only one solution can
> satisfy them - that applies both to PERC and to encoded-data APIs.


And I agree: you write requirements to state what will acceptably solve 
the problem/use-cases.


>
> That said - if we have a requirement on how RTX/FEC is handled, we
> should get that written down and agreed upon. Currently we have no such
> requirement.
>
> (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.

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam