If there is a bootstrap server, then:
1) If the bootstrap server returns an empty list, the node can start as
the first node owning the overlay.
2) If the bootstrap server returns a non-empty list and none of the nodes
are online, the outcome is use case dependent. The node may report an
access failure or it may start as the first node owning the entire
overlay.
If there is no bootstrap server, then:
1) If the broadcast/mDNS does not return any peer, the node can start as
the first node in the overlay.
2) If the broadcast/mDNS returns peer(s), but they are not
reachable/offline, the outcome is use case dependent as mentioned in (2)
for bootstrap server case.
If the nodes are preconfigured with bootstrap peer(s) address and the
bootstrap peers fail to respond, it is a case of access failure.
-s
On Thu, 17 Jul 2008, Brian Rosen wrote:
Clearly use case dependent, but at least I understand the question.
For a use case like ad hoc MANET voice connectivity, there is no case 2.
Clearly for something akin to Skype, there would be, assuming that you can
actually reach someone to report the problem when you can't reach the
overlay.
Brian
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Eric Rescorla
Sent: Thursday, July 17, 2008 10:53 AM
To: David A. Bryan
Cc: P2PSIP WG
Subject: Re: [P2PSIP] Boot strap peers
Let me try to rephrase what I think the real issue is:
If a node starts up and cannot connect to any other nodes, there
are two possibilities:
1. It's the first node and should start up as owning the entire
overlay.
2. It can't access the overlay and should report an error.
How does a node determine which case is relevant?
-Ekr
At Thu, 17 Jul 2008 10:39:17 -0400,
David A. Bryan wrote:
I'm actually a bit confused what you are asking on this one.
In theory, any peer can bootstrap one in, from the way I read it (and
it certainly *should* be that way). Hence the ability to use cached
peers. The configuration described in 13.2 lists those peers that are
serving as bootstrap peers. I can see two things you might actually be
asking here:
So if your question is "How does a peer add itself to the list?" I
think:
I'm don't think a peer itself should always be deciding that it is a
bootstrap peer. How the file described in 13.2 is created seems best
left as a configuration issue. In an open, non-managed public internet
overlay, perhaps peers can decide and add themselves, but in a managed
network, that file is likely only going to be modified by the operator
and contain a list of some well known, likely service
provider/enterprise operated peers.
My 2 cents would to leave how to decide who is in there out of scope
for this document.
If your question is "How does a peer decide it is a good candidate to
be a bootstrap peer, in the absence of operator provided peers?", this
is much more tricky. Much like selecting a relay peer. I'm not sure
the answer to that one, and it seems a very tricky problem. It also
seems the ALTO work may come into play in that case.
David (as individual)
On Wed, Jul 16, 2008 at 3:04 PM, Cullen Jennings <[EMAIL PROTECTED]>
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
--
David A. Bryan
[EMAIL PROTECTED]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
