> How does the method in SEP work as service provider population > grows > or shrinks? I like some of the properties it has, but it seems > like > as server population drops, it's relying on random chance that a > particular path will happen to traverse a neighbor of a service > provider. As population drops, that probability goes down. If the key-id of the message is chosen at random, it may take more transactions to get the service provider. That needs some experimental data to see to which extent of the population of the service provider, the searching will succeed within reasonable time period. We will do some work after this IETF meeting.
Another method to improve the success rate if the population is low, is to make the message traverse the overlay hop-by-hop until it finds matched entry. It may take longer time and may not stop. So maximum hops may be needed to prevent this happen. > ReDiR handles this through its adaptation. Reload (assuming the > population is predicted in advance), works, but if a peer being > able > to provide the service is very rare, may require the service > providers to do a lot of STOREs to achieve the desired density of > registrations. IMO, it is not easiy to predict the population. For TURN service, we could predict from some statistical data on the percentage of different types of NATs. But for other service, it may be hard to achieve the percentage. In another way, if the population changes over time, the service providers should do additional work accordingly. On the other hand, the service provider also should maintain 1/percentage <key,value> pair. It should periodi cally update the state. JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
