Re: Gaming use cases and ICE

On 27.05.2018 21:45, Bernard Aboba wrote:
> On May 27, 2018, at 6:23 AM, Lennart Grahl <lennart.grahl@gmail.com> wrote:
>>
>> 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.
> 
> [BA] Abstractions like sockets.io deliver the message to all room members but this happens on the server and is opaque to the application, simplifying the logic there. Without support for parallel forking, you would need to discover the Answerers first (1 RTT), then complete an O/A exchange (at least 0.5 RTT if piggybacked on discovery).

Ah, because you don't know the amount of participants. Got it. However, 
I would claim that in most cases this information does not need to be 
requested but could be sent back as part of the signalling channel's 
handshake (which you almost always have) and then there's no advantage 
since you still need an answer/remote parameters from all participants.

> 
>> I don't understand why that would result in faster connection establishment. Can you elaborate?
> 
> [BA] Gathering only occurs once, with a filtered candidate set. For example, a relay candidate can be offered, allowing media to ge started up immediately.

Okay, since gathering can take a while this is indeed an advantage.

> 
>> 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?
> 
> [BA] Total sockets can be an issue on servers but typically not on clients.

Agreed.

>> 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?
> 
> [BA] TURN mobility (supported in Ortc lib) enables IP address changes while minimizing media glitches via use of a relay. So it does not encounter this problem (which could be addressed while media is still flowing via an ICE restart).

I would prefer having a form of mobility that does not require TURN. But 
it seems mobility should already be possible by accepting peer reflexive 
candidates.

>> 3. Would this allow to reuse TURN allocations?
> 
> Yes.

Good. Then I would propose adding this to the selling points of parallel 
forking since it wastes less resources of TURN server providers. :)

Cheers
Lennart

Received on Sunday, 27 May 2018 22:35:59 UTC