- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Thu, 31 May 2018 18:43:40 +0200
- To: public-webrtc@w3.org
- Cc: Michael Tuexen <tuexen@fh-muenster.de>
Supplementary to "Long-term Connections". Michael Tüxen suggested to provide more fine granular control over data channel mechanisms, for example: - Setting the retransmission timeout (RTO) values for initial/min/max. - Setting the maximum amount of retransmissions before the association is aborted (RTX max). - Turn the heartbeat on/off and settings its interval (already mentioned that previously). - ... and potentially further settings exposed by the SCTP API. Cheers Lennart On 22.05.2018 20:54, Lennart Grahl wrote: > Hi, > > below are some use cases I would like to have covered by WebRTC NV. I > will only mention use cases of existing or new applications where the > API or the underlying transports are not sufficient. And I'm not an > expert in all of those areas where I'm proposing ideas for solutions. ;) > > ## Long-term Connections > > Internet of Things / Low Power Devices or mobile applications require a > resource efficient (low CPU usage, low non-application based network > activity -> hopefully low battery usage) long-term connection. IoT > devices with sensors may want to periodically (but possibly > infrequently) send sensor data. Applications that provide a way to > mirror an application on a remote device (such as Threema Web [1]), or > applications that synchronise user data (such as a hypothetical P2P IDE > in the browser with the ability for collaboration) also require > long-term connections and are frequently in the background. > > My ideas on how to improve WebRTC for this: > - ICE: More control over candidate gathering for the application. Limit > the amount of candidates gathered, omit specific networks, types (UDP, > TCP, candidate type), etc. > - ICE: Significantly reduce connectivity checks (controllable by the > application) or turn them off entirely if feasible (when no NAT in > between). > - ICE: Pruning of candidate pairs (controllable by the application). > - ICE: Letting the application control which candidate pair should be used. > - SCTP: Allow to change the heartbeat interval or turn it off entirely > (this is a minor optimisation). > - General: Less RTTs for connection setup which *includes* less RTTs > required for signalling.
Received on Thursday, 31 May 2018 16:44:05 UTC