W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

Re: WebRTC NV Use Cases

From: Lennart Grahl <lennart.grahl@gmail.com>
Date: Tue, 22 May 2018 20:54:41 +0200
To: public-webrtc@w3.org
Message-ID: <9c455cd3-28b2-54da-52fa-91b890c9bbba@gmail.com>

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.

## Mobility

The above use cases may also be applied on a device that is moving 
between networks. IIRC, an ICE restart requires an active signalling 
channel which will probably not survive a network change. Furthermore, a 
candidate pair may deteriorate and switching to another candidate pair 
could provide a "better" connection (where "better" of course depends on 
the use case, so the application should be able to control this or at 
least state an intent).

- ICE: Handover to new candidates. I know that there is "continuous 
gathering" but IIRC that is unofficial. I have not used it myself so I 
can't comment on whether that is a good solution and I'm uncertain 
whether this works without exchanging further signalling data (and I 
would prefer a solution that doesn't).
- ICE: Intelligent choosing of a "better" candidate pair (if it hasn't 
been pruned). By "intelligent" I mean based on live data such as RTT, 
throughput, etc.

## High Throughput / High Performance

Transferring arbitrary data between two peers should be blazing fast (it 
isn't in most implementations but this is an implementation problem). 
Transforming data should be blazing fast, too.

- API: Worker support (see https://github.com/w3c/webrtc-pc/issues/230). 
This would also allow for transforming the data (such as an additional 
encryption layer) in a worker and would reduce copying.
- API: WHATWG stream support (this has already been proposed for data 
channels, see https://github.com/w3c/webrtc-pc/issues/1732 and we 
probably need to discuss whether this should be in 1.0 or in NV) to 
provide a flow control surface (and prevent backpressure).
- API: A mandatory permission request for direct connections (mode 1) as 
an alternative to gUM. Other non-A/V or A/V receive only use cases would 
also benefit from that. This would also solve our problems with privacy 
extensions that hate WebRTC for leaking IPs because we could possibly go 
restrictive (srflx) by default.

## Other

These are use cases that have already been proposed in one way or another.

- A/V transport over data channels: I think you already started 
discussing an approach that would allow for transferring A/V via an 
arbitrary transport. And I'm not an A/V expert. :)
- SFUs without the ability/need to decrypt the payload.


[1]: https://github.com/threema-ch/threema-web
Received on Tuesday, 22 May 2018 18:55:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC