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

ulpfec is better than RTX?

Given that ulpfec fec header has a 10 bytes overhead and flex fec has a 
12 bytes overhead header compared to the 2 bytes of the RTX OSN, I am 
not really sure I agree with your statement.

On 15/12/2018 0:23, Cullen Jennings wrote:
> 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 Saturday, 15 December 2018 07:58:57 UTC