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

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).

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. 

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. 

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. 

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

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

Received on Friday, 6 October 2017 22:05:28 UTC