Song Haibin wrote:
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.
Unfortunately, I don't think it's that trivial. Consider the following
cases:
- many hosts with public addresses are behind firewalls (very common at
universities)
- some people use "public" address spaces behind NATs (they shouldn't,
but they do)
- some overlays may exist entirely inside a private address space (an
internal overlay for a large company)
- peers behind "friendly" nats are perfectly capable of being 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?
I'm not sure I understand how the concern about compatibility is
involved here. Presumably a non-peer bootstrap server needs some way of
being configured with actual peers, so it would know if the overlay is
currently being started. I'm still not sure I see the use in that
setup, though.
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.
Yes, that's what I referred to as "falling back to the other mechanisms"
Bruce
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
