Re: Call for adoption - WEBRTC-QUIC

On 23/11/2018 10:52, westhawk wrote:
> One problem that QUIC_theoretically_  solves is the congestion control
problem by bringing everything under
> the same protocol, but only if you move all media to QUIC and ban RTP.

I thought Peter's presentation covered RTP over QUIC by exposing some of
the internal workings of RtpSender/RtpReceiver?
I don't think exploring new transports commits us to banning anything. The
benefit of modularization and piping would be *more* choice, not less;
assuming we don't bite off more than we can chew.

On Fri, Nov 23, 2018 at 11:18 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 23/11/2018 11:06, westhawk wrote:
>
>  On 23 Nov 2018, at 11:02, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> <sergio.garcia.murillo@gmail.com> wrote:
>
> On 23/11/2018 10:52, westhawk wrote:
>
> One problem that QUIC_theoretically_  solves is the congestion control problem by bringing everything under
> the same protocol, but only if you move all media to QUIC and ban RTP.
>
> Just for the sake of completeness, the other problem that QUIC solves is the sync between media and data, something that is not achievable today between SCTP and RTP (AFAIK).
>
> I’m Nit picking:
> It only _potentially_ solves it - since you there are currently _no_ IETF RFCs that address this issue as far
> as I’m aware - and again this is only true if you disable use of RTP and depend on some future
> “realtime media over QUIC" RFC and
> a "synchronisation of data and Media over QUIC” RFC
>
>
> I agree and disagree, given that media frames will be agnostic to QUIC (or
> that is the promise), it is up to the app to add sync metadata to both
> media frames and data over QUIC. There is no need to sync on receiver side
> (bad wording on my side) but just be able to correlate data with media
> frames. Anyone, please correct me if my understanding is incorrect.
>
> All that, given that an unreliable QUIC stream mode suitable for RTC is
> specified in IETF, of course.
>
> Best regards
>
> Sergio
>