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

I don’t know why we ever put RTX in WebRTC - it was clearly so suboptimal in RTP in general that we created much better things to replace it - like ULPFEC. I’d be in favor of removing it. 


> On Nov 29, 2018, at 7:33 AM, Harald Alvestrand <harald@alvestrand.no> 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.
> 
> 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.)
>

Received on Friday, 14 December 2018 23:24:20 UTC