Salman, ----- Original Message ----- From: Salman Abdul Baset <[EMAIL PROTECTED]> Date: Friday, July 18, 2008 6:56 am Subject: Re: [P2PSIP] Boot strap peers
> If there is a bootstrap server, then: > 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. Yes, here I think if none of the nodes in the return list are online, it delays the JP's joining progress greatly and impacts user experience. If the bootstrap server keeps the table of bootstrap peers, it should refresh the entries in this table periodically for joining efficiency. Caching mechanism for bootstrapping also has this problem. > 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. It is true if all nodes in the overlay must be within the reachability of broadcast. > 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. I agree. BR Song Haibin > -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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
