Re: Call for adoption - WEBRTC-QUIC

> On 23 Nov 2018, at 11:20, 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> <mailto: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 of which would be entirely possible with the existing SCTP transport using similar if not identical mechanisms.

> All that, given that an unreliable QUIC stream mode suitable for RTC is specified in IETF, of course.
> 
Which SCTP already has.

Which brings us back to the essential argument - browser and server developers would rather work on 
something from scratch with QUIC than work on the existing codebase of SCTP. 
I understand that argument, but as one of the few people here to have worked with SCTP,
I’m here to say it isn’t anything to fear….

T.
> Best regards 
> 
> Sergio
>