Hi Bruce, First, I think peer selection is use case dependent, and is very trivial. Maybe we should just select peers among those who have public address to be bootstrap peers. Peers behind restricted NAT/FW should not be selected as bootstrap peers.
Second, ASAIK, many people like the bootstrap server method to be used for its simplicity. In the case the bootstrap server is used, inability to locate a bootstrap peer is due to the incapability of the bootstrap server, unless the joining peer can not setup connection with any of the nodes in the overlay. If the joining peer is the first node in the overlay, the bootstrap server should be aware of that. How can we provide a bootstrap server that can't provide valid bootstrapping function? Third, cached neighbors can be used for bootstrap, but there at least needs a last resort in the case that none of the cached peers can be used for bootstrap. BR Song Haibin >Sent: Friday, July 25, 2008 4:06 AM >Subject: Re: [P2PSIP] Boot strap peers > >Cullen Jennings wrote: >> >> How does a node decide it should be a bootstrap peer. The current >> document more or less say configuration. >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> > >So points I see in various comments are that: > >- bootstrap peer selection is going to be use-case dependent >- the proper reaction to inability to locate a bootstrap peer is >use-case dependent >- how can you figure out if you're a good bootstrap peer? > >options for obtaining bootstrap peers include: >- configuration file >- cached previous neighbors >- mDNS etc > >I think the real question here is what needs to be in the base draft and >what is appropriate for extensions or simply implementation/deployment >specific. I would like to propose: > >- the configuration file can contain a list, can indicate whether local >search (mDNS, etc) can be used, and can indicate whether no bootstrap >peers being contacted is a failure (there's a minor bootstrapping(!) >problem here for starting a new overlay, but that's not too bad) >- the draft will specify the format of the list and the mDNS parameters. >- caching previous peers will be left as an option for implementers, >presumably falling back to the other mechanisms. (I don't see a reason >to want to prohibit this, but am open to suggestions.) >- determining whether you make a good bootstrap peer and whether/how to >update the configuration list will be out of scope for the base draft. > >Bruce > >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
