Re: [w3c/ortc] RTCQuicTransport: Addition of createStream and onstream (#783)

On Fri, Oct 6, 2017 at 3:06 PM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Sergio said:
>
> I understand that the purpose is to provide a low level api as close as
> the quick protocol as possible, but not sure if this may lead to
> undesirable side effects when dealing with unoredered/unreliable modes.
>
> Let me try to explain, for reliable/ordered mode, the idea is quite clear
> and a stream API matches exactly what I would expect. But for
> unordered/unreliable modes I would expect a datagram API instead of an
> stream API.
>
> It could be argued that this datagram API could be implemented on top of
> the quic stream API, I assume that sending each datagram in a single quic
> stream. That would work, but I think it would create quite a lot of bloat,
> because for each datagram you will have:
>
> create sream
> send data
> close stream
> onstream event
> read data from stream (1 or several ondata events?)
> onstreamclosed event??
>
> If that is the intended behavior (and I don't know how it could be
> implemented otherwise), I think it would be better to create an ad-hoc
> datagram api to avoid the extra js method calls and events (which could
> impact on app performance).
>

Implementing the message-based API on top of the stream-based API, as you
point out, is very easy.  The question is one of performance.  If JS cannot
be performant enough, then we can easily push such an implementation down
into the browser and expose that to JS.  But we won't know if that's
necessary until we implement the API and write the JS and measure.  At that
point we will know and can decide.

I originally added such a method to my design but then realized that it was
premature optimization.


>
> IMHO, it should provide something like:
>
> transport.send(blob,{unreliable:true});
> transport.onmessage((event) => {...});
> If you think it is not cleaner to add the API directly on the transport,
> maybe it could delegate it to a separate object (but it can be only one per
> transport).
>
> [BA] I share some of your concerns about the potential applicability of
> QUIC for unreliable data exchange in WebRTC.
>
> For one thing, unreliable transport isn't even a QUIC WG work item, and
> some have argued it isn't within the QUIC WG charter.  So it could be quite
> a while until the IETF standardizes support for unreliable QUIC transport.
>

QUIC does have unreliable transport if you're willing to many streams (one
message per stream), which I think is a fine approach as long as it's
performant enough.


>
> That aside, attempting to layer an RTCDataChannel construction on top of
> QUIC transport is not all that straightforward.  As you say, a new stream
> would be needed for each message.
>
>
I don't see why that is not straightforward.  We've already implemented a
prototype of this twice, and both times it was easy and a small amount of
code.


> Although QUIC streams are supposed to be very light weight, the JavaScript
> overhead to create and garbage collect all the objects, fire the events,
> etc. seems like it could be considerable.
>

We won't know until we measure.  And if there is an issue at that point, we
can also provide a higher level API.  I don't think it will be necessary,
but we'll measure.


>
> Also, the data channel ID would need to be carried somewhere, so an
> RTCDataChannel header would need to be designed.
>

That's exactly why we want to provide a low-level API for this: so that
each app can do it how they want and we don't need an IETF WG to define how
to stick an ID in a header (of course if you want one, go ahead, just
implement it in JS instead of in the browser).

It's really quite simple for most apps. Just make the first byte of each
stream an ID, and you're done.


>
> So overall, a stream API seems largely applicable to reliable/ordered mode.
>

It's applicable to both.