Re: Conformance (Re: Raw data API - 4 - direct RTP access)

On Thu, May 31, 2018 at 1:05 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 30. mai 2018 20:06, skrev Peter Thatcher:
> > You're advocating, then, for a high-level API.   On the flip side, an
> > app should be allowed to do many non-standard or custom things as well.
> > And that requires a low-level API.  And that's the root of the tension
> > between high- and low-level APIs: if you can control more, you have to
> > do more.
> >
> > What objection do you have in these things being provided by libraries
> > instead of being baked in the browser?
>
> We're getting at an important point here - probably best thought of as
> "security considerations".
>
> If an app can do something, and can do it right or wrong, the overall
> conformance of the system to a specification depends on the browser
> doing it right AND the app doing it right.
>
> If we take away the power of the app to do it wrong, overall conformance
> of the system depends only on the browser doing it right.
>
> There are cases where that matters (especially if you're selling into
> places where certifications are taken seriously); there are cases where
> it doesn't. Security is one of the areas where it matters; congestion
> management is another.
>

> The more the browser is supposed to guarantee, the more things need to
> be kept away from the application. And vice versa - if we find that
> things can't cause too much harm, the value of keeping them away from
> the application becomes lower.
>
>
I agree with this assessment, and I think there are 3 areas where the
browser must maintain control are:

1.  Security (ICE consent, per-hop crypto, either DTLS-SRTP or QUIC)
2.  Congestion control (either RTP-based, SCTP, or QUIC; also, ICE pacing)
3.  Packet formats and low-level protocols (ICE, DTLS, RTP, RTCP, SCTP, and
QUIC)

The last one is a bit squishy.   I say "low-level protocols" because I
think the browser should control the packet formats and crypto handshakes
and RTP/SCTP/QUIC acks, and that sort of thing.  But there's a lot of room
for the app to directly control things like when ICE checks are sent, which
ICE candidate pairs are selected (or renominated), when ICE candidates are
gathered, what RTP PTs, SSRCs, timestamps, header extensions IDs, and
payload packetizations are used, what goes in QUIC streams, how many QUIC
streams there are, etc.

I say we control those 3 and let apps do whatever they want.  If they want
to make an ICE stack that's "wrong" because it has continual gathering and
renomination and no freezing, so be it, as long as consent checks and
pacing are enforced.  If they want to make up a new RTP packetization
format or header extension or FEC scheme that's "wrong", because it doesn't
have a standard yet, so be it, as long as the hop-by-hop encryption and
congestion control is enforced.  If they want to use SCTP for sending media
or use RTP for data channels even if it's "wrong" because no one else does
that, so be it, as long as its encrypted and congestion controlled and fits
on top of existing packets/protocols.

I don't think the browser should be in the business of telling web apps
what's "right" or "wrong" beyond those minimum things.