RE: Issue 174: When is an IceGatherer allowed to prune host, reflexive and relay candidates?

Some questions about the prune timeout: 

Is it the incremental time (in seconds?) after which all candidates (host, server reflexive, relay) are removed from the IceGatherer? 
Or does it only apply to some portion of the candidates (e.g. host candidates from live interfaces do not timeout)? 
Is there a minimum or maximum value?  

Is there an event on expiration of the prune timeout? 
How is it expected to be used in communication between peers? 
     For example, would a local peer communicate the prune timeout to the remote peer?
     How is the time between IceGatherer construction and receipt of the Answer by the remote peer adjusted for?  Via a timer set on the local peer?  


________________________________________
From: Robin Raymond [robin@hookflash.com]
Sent: Friday, February 06, 2015 7:06 PM
To: Bernard Aboba; Roman Shpount
Cc: public-ortc@w3.org
Subject: Re: Issue 174: When is an IceGatherer allowed to prune host, reflexive and relay candidates?

+1. I’m for (b) with BA’s actor suggestion and agree w/ Roman’s reasoning..

-Robin


On February 6, 2015 at 7:07:31 PM, Roman Shpount (rshpount@turbobridge.com<mailto:rshpount@turbobridge.com>) wrote:

On Fri, Feb 6, 2015 at 6:47 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
Robin Raymond said:

"Possible solutions:
(a) IceGatherer is told to "gather()" with a prune timeout, and candidates remain warm until the timeout has completed (and can be optionally extended by gather() again with another future timeout before the last timeout completes)
(b) IceGatherer keeps all host, reflexive and relay candidates "hot" until a "IceGatherer.prune()" method is called where it's now allowed to prune out any non-warm candidates (i.e. candidates that have not sent or received checks / data within a standard ICE consent timeout).
(c) IceGatherer keeps all host, reflexive and relay candidates "hot" so long as a single incomplete IceTransport is attached to the IceGatherer, i.e. keeping the IceGatherer warm could be done by keeping an unused IceTransport around until it's disposed."

[BA] Another option worth considering would be to add an (optional) prune timeout to the IceGatherer constructor.  That way, it would not be necessary to call gather() to begin the gathering process; gathering would start upon construction as it does now.   I realize that there is another potential use of .gather() which is to enable ICE gathering to occur again without changing the password/ufrag.  But that seems like an issue distinct from this one.


We would still need gather() to extent the timeout.

After some consideration I do like the having an optional parameter in the IceGatherer constructor for prune timeout in combination with gather() method to extend the candidate availability. The benefit of this option is that it will give the desired behavior for the most common use cases without any extra client code while allowing to implement more complex forking scenarios.

I dislike (b) since the programmer can forget to call prune which will keep all the candidates for the duration of the call without giving any indication that anything is done wrong.

Option (c) is undesirable since it requires to keep an IceTransport for no other reason except to keep the candidate hot.
_____________
Roman Shpount

Received on Saturday, 7 February 2015 13:34:38 UTC