Re: Gaming use cases and ICE

On 27.05.2018 08:13, Bernard Aboba wrote:
> Sylvia asked:
> 
> "What's the advantage of this over sending multiple offers in parallel in
> JavaScript (asynch)? In my opinion this is needlessly complicating things -
> you need to manage the connection with each endpoint separately anyway."
> 
> [BA]  There are a number of scenarios in which latency and join time need to be minimized, such as in games.
> 
> In a mesh conference with parallel forking (such as is supported in Ortc lib), 1 offer can be sent versus (n-1) offers without it.
> So not only does it save 0.5 RTT, but it also reduces code complexity and total packet traffic.

I think Silvia has a point that this offer needs to be duplicated 
somewhere, so it's questionable whether it requires less traffic. And 
I'm also wondering why it would spare half an RTT.

> By separating the IceGatherer and IceTransport, it is possible to share local candidate state across multiple IceTransports (each of which are constructed from a single gatherer).
> Combined with Ice candidate filtering, this allows media to be sent after only a single check (e.g. using a TURN server).
> 
> The end-result is that the mesh conference comes up much more quickly.

I don't understand why that would result in faster connection 
establishment. Can you elaborate?

IIRC an RTCCertificate can be reused already, so the only advantage I 
see is reusing existing UDP sockets of the local candidates. A few 
questions on that:

1. AFAIK UDP sockets are extremely cheap. Do we have use cases where 
having many UDP sockets is a problem, maybe on embedded platforms?
2. IIRC this technique requires multiplexing based on the source 
addresses for incoming packets, so they can be mapped back to their ICE 
transport. Wouldn't this prevent (possible) mobility extensions in the 
future where the UDP source IP changes on-the-fly?
3. Would this allow to reuse TURN allocations?

Cheers
Lennart

Received on Sunday, 27 May 2018 13:23:38 UTC