Re: Towards a new charter for the WebRTC Working Group

Here are a few things:

- Deployment.  A lot of people have substantial QUIC deployments, and the
number and scope of such deployments is growing.  Whereas the scope of
deployments of SCTP is much more limited.  We have many people asking for
QUIC data channels because they want to do client->server data channels and
they have QUIC on there servers, but they don't have (and don't want to
have) SCTP.

- Ease of deployment.   No offense to usrsctplib, but I hear a lot of
complaints about having to use it to make a non-browser WebRTC endpoint.
It's one of the biggest complaints we hear about WebRTC data channels: the
pain of terminating SCTP (and DTLS).  That's a big reason why people want
QUIC. There will soon be many implementations to choose from (if there
aren't already) and you only have to terminate one protocol, not two (DTLS
and SCTP; ignoring ICE).  This is closely related to #1.

- Code maturity.  The existing QUIC implementation in Chrome is mature and
robust.  We can expect many QUIC implementations to be mature and robust in
short order.  Meanwhile, no offense to usrsctplib, but in my experience,
it's just not as mature and robust.  For example, trying out BBR in QUIC
was a matter of flipping on a flag.  Doing so in SCTP would probably be a
lot more work.

- Setup time.  QUIC requies a lot fewer round trips than SCTP.

- Future protocols.  There's a lot of interest in doing media over QUIC.
There isn't any in doing media over SCTP (that I know of).  We don't want
to just do data channels.  We want to do other things as well, and that's
the direction people are moving.


There are probably others, but those are some of the ones that matter to me
right now (and those who have asked us for QUIC "data channels")



On Sat, Jan 6, 2018 at 5:32 AM Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

> > On 1. Jan 2018, at 23:18, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> > What are the plans for the protocol pieces for the new items?  I
> > haven't seen any plans - or internet-drafts - for those, and the bulk
> > of the work for some of these items is protocol work.  For instance, I
> > can understand why the group might choose not to rely on SDP for
> > negotiating new features, which leads to some API work, but the bulk
> > of the QUIC datachannels work is in defining protocols, not the API.
> What are the benefits of using QUIC datachannels compared to SCTP
> datachannels?
>
> Best regards
> Michael
> >
> > On Wed, Dec 20, 2017 at 7:58 PM, Dominique Hazael-Massieux <dom@w3.org>
> wrote:
> >> Hi,
> >>
> >> Our current Working Group charter is set to expire end of March:
> >>  https://www.w3.org/2015/07/webrtc-charter.html
> >>
> >> Given the time needed to get a new charter reviewed and adopted, the
> >> Chairs and Staff Contacts have started working on a propose updated
> >> charter in a github repo:
> >>  https://github.com/w3c/webrtc-charter
> >>
> >> The results of these updates are visible at:
> >>  http://w3c.github.io/webrtc-charter/webrtc-charter.html
> >>
> >> The detailed diffs can be seen at:
> >>
> >>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2015%2F07%2Fwebrtc-charter.html&doc2=http%3A%2F%2Fw3c.github.io%2Fwebrtc-charter%2Fwebrtc-charter.html
> >>
> >> Many of the changes in the charter come from alignment with the W3C
> >> charter template [1], or reflect changes in the external groups we're
> >> expected to coordinate with. The two main substantive changes we propose
> >> are:
> >>  * addition of deliverables for QUIC, ICE Extension, DSCP marking
> >>
> >>  * adoption of the more "permissive" license for our documents (W3C
> >> Software and Document license instead of our current W3C Document
> >> license) - the goal is to align with other W3C Working Groups, and
> >> facilitate exchanges with Community Groups
> >>
> >> The goal is for this document to serve as a starting point for
> >> discussion in the group - once the group agrees on the content of its
> >> new charter, we will then bring it to W3C management and the W3C
> >> Advisory Committee for review, aiming to get eventual W3C Director's
> >> approval.
> >>
> >> We will discuss this on our next call in January, and we welcome
> >> discussions either on the list or in the github repository in the
> meantime.
> >>
> >> Thanks,
> >>
> >> Dom
> >>
> >> 1. https://w3c.github.io/charter-drafts/charter-template.html
> >>
> >
>
>
>