Re: Call for adoption - WEBRTC-QUIC

I would say that if congestion control problem can be solved better using QUIC rather than RTP then I would support it. For both client-server and client-client. 

> On 23 Nov 2018, at 12:52, westhawk <thp@westhawk.co.uk> wrote:
> 
> 
> 
>> On 22 Nov 2018, at 18:26, Henrik Boström <hbos@google.com> wrote:
>> 
>> I support adoption too. I would be excited to see the working group tackle the NV stuff that Peter presented as possible further down the line things (like media over QUIC). Having access to transports, streams and encoders/decoders in service workers would be incredibly powerful. Even if we don't think about NV use cases, RTCPeerConnections are heavily used for their data channels and QUIC seems to solve several problems that would make data transfer nicer; getting rid of SDP, less handshakes, etc.
> 
> At the risk of re-starting an old discussion. we could get rid of SDP tomorrow for SCTP data channels. 
> Exactly the same info is needed to start a QUIC session as an SCTP/DTLS one.
> You need to exchange:
>  at least 1 ICE candidate with credentials
>  Fingerprint
> Everything else in the SDP is redundant.
> 
> We have repeatedly stated removing at least one round-trip from SCTP/DTLS setup is easily done
> by skipping the cookie exchange which is not needed if you have already done a DTLS handshake.
> - (this is IETF talk really).
> 
> So (IMHO) QUIC doesn’t solve either of those problems.
> 
> 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.
> 
> T.
> 
> 
> 
>

Received on Friday, 23 November 2018 09:59:34 UTC