Re: Call for adoption - WEBRTC-QUIC

On Wed, Nov 21, 2018 at 5:34 AM T H Panton <thp@westhawk.co.uk> wrote:

> > On 21 Nov 2018, at 08:15, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> >
> > On 11/20/2018 09:09 PM, Roman Shpount wrote:
> >> I see what is being added, but I see no explanation in this document or
> announcement why it is being added.
> >
> > the presentation given by Peter at TPAC is at
> https://www.w3.org/2011/04/webrtc/wiki/images/a/a8/WebRTC_QUIC_status.pdf
> >
> > and Peter's presentation of it is in the video recording.
> > It may answer some of your questions.
>
> I'm mildly anti adoption of the document at this point, Peter's
> presentation reenforces that.
>

After looking through the presentation I am still not convinced this should
be adopted. I think there are real problems described in the presentation
but I do not think this document is the right solution.

>From what I can see there are several groups of problems described (and my
feedback to them):

1. Cannot use P2P communications from Service Workers -- requires an API
update in order to be implemented in a safe to use manner. Probably the
biggest functionality gap in DataChannel now. Currently this is overly
complicated since DataChannel is currently joined at the hip to audio/video
which are not desirable in Service Workers.

2. Streaming interface and back pressure functionality -- this can be
currently implemented using a JavaScript library on top of DataChannel, but
can be be easier to use and more efficient when implemented in the browser.

3. Current data channel API is very low level and very complex -- In my
opinion this is a matter of perception, but I do not think proposed
protocol is any better. We will definitely benefit from DataChannel
implementation which is not connected to audio/video and SDP.

4. Please don't do SCTP to my server -- I have not seen any indication that
this is anything except desire for a new cool protocol instead of fixing
what we have

Overall I feel this low-level QUIC transport API is the wrong place to
> start.
>

I completely agree with this. I think we should start from desired
functionality and hide QUIC/DataChannel under URL/Transport object so that
the same consistent interface can be used for P2P and peer-to-server two
way communication with controllable reliability. Once the API is defined,
correct underlying protocol or protocols can be selected with actual
protocol extensions defined by IETF. This being said I am not sure the
problem is entirely within RTC group domain and that new protocol should
even have an RTC prefix.

We should be drafting API's that give desired access to streams and media -
> testing them out over SCTP, then moving to QUIC once it is ready.
>

Once again, agree completely.


> Cart before Horse IMHO
>
>
I think it is more like we got a horse (QUIC) and now looking for a cart.

Regards,
_______________
Roman Shpount