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

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 Thursday, 29 November 2018 14:34:09 UTC