Subject: [P2PSIP] Boot strap peers

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jul 2008 12:04:59 -0700

How does a node decide it should be a bootstrap peer. The current  
document more or less say configuration.
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 17 Jul 2008 10:39:17 -0400

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-masked]> wrote:
>
> How does a node decide it should be a bootstrap peer. The current document
> more or less say configuration.

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Jul 2008 07:53:09 -0700

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,

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 17 Jul 2008 14:03:05 -0400

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-masked] [mailto:[email-masked]] 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
>

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 17 Jul 2008 18:56:42 -0400 (EDT)

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

---

From: songhaibin 64081 <[email-masked]>
Date: Fri, 18 Jul 2008 15:06:28 +0800

Hi Cullen,

I think there are two ways to decide the bootstrap peers. 

First, the bootstrap server is easy to determine which peer to be the bootstrap peer if it can get all online peers' information from a certain entity, e.g., from a server that keeps all peers' information (Enrollment server or else?). 

Second, some reputation mechanism can be used to select the bootstrap peer by the overlay itself. I think in some scenarios this is practical.

There should be a status maintenance mechanism between a bootstrap peer and the bootstrap server. At least when a bootstrap server is going to leave the overlay, it must notify the bootstrap server for its leaving, so that the bootstrap server can keep a list of effect peers for bootstrapping.

I think we should keep in mind that if we want the bootstrapping progress to be effective, we should ensure the list of bootstrap peers alive and easy to access(not behind very restrict NAT or FW). 

Best Regards,
Song Haibin
Email: [email-masked]
Skype: alexsonghw
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 18 Jul 2008 15:30:54 +0800

> seems the ALTO work may come into play in that case.

My concerns for the bootstrap peer is whether RELOAD provide a mechanism to make sure the candidate bootstrap peer has a unrestrictive connectivity, i,e, having public address and no firewall or behind address-independent firewall. 

In my mind, a peer could know whether or not it is behind NAT with the help from a rendevous point which plays a anchor role and be on the public internet. The two candidate rendevous point is enrollment server and bootstrap server.

---

From: songhaibin 64081 <[email-masked]>
Date: Fri, 18 Jul 2008 16:08:20 +0800

Salman,

----- Original Message -----
From: Salman Abdul Baset <[email-masked]>
Date: Friday, July 18, 2008 6:56 am
Subject: Re: [P2PSIP] Boot strap peers

> access failure or it may start as the first node owning the entire 

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. 

> the first node in the overlay.

It is true if all nodes in the overlay must be within the reachability
of broadcast.

> bootstrap peers fail to respond, it is a case of access failure.

I agree.

BR
Song Haibin

> >>> it certainly *should* be that way). Hence the ability to use 
> cached>>> peers. The configuration described in 13.2 lists those 
> peers that are
> >>> So if your question is "How does a peer add itself to the 
> list?" I
> >> think:
> >>>
> >>> 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
> >>> My 2 cents would to leave how to decide who is in there out of 
> scope>>> for this document.
> >>>
> >>> 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
> >>> On Wed, Jul 16, 2008 at 3:04 PM, Cullen Jennings 
> <[email-masked]>>> wrote:
> >>>>

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 24 Jul 2008 16:05:30 -0400

> document more or less say configuration.

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

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 25 Jul 2008 10:42:28 +0800

> - cached previous neighbors

I think bootstrap server should be included. 

> - the draft will specify the format of the list and the mDNS 
> parameters.- caching previous peers will be left as an option for 
> implementers, 

In RELOAD, bootstrap peer should have public address which is very important for overlay to function properly. So if it is not within base draft, I think we need other draft to address this issue, maybe with BCP.

---

From: Song Haibin <[email-masked]>
Date: Fri, 25 Jul 2008 11:33:28 +0800

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

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 25 Jul 2008 09:03:36 -0400

> I think bootstrap server should be included. 

Currently reload doesn't have a notion of a bootstrap server (separate 
from a bootstrap peer).  I'm not really sure what the purpose of having 
a non-peer bootstrap server would be, actually.   OTOH, I don't think 
the existing protocol would need to be changed at all to support 
it---the JP doesn't need to know it's not a bootstrap peer it's 
contacting and the routing wouldn't be any different from the JP or AP's 
perspectives.

So I think if one did have a bootstrap server speaking reload, I think 
it would just appear in the list of bootstrap peers and be treated the same.

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 25 Jul 2008 09:12:25 -0400

> bootstrap peers. Peers behind restricted NAT/FW should not be selected as

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.

> 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.

> a last resort in the case that none of the cached peers can be used for

Yes, that's what I referred to as "falling back to the other mechanisms"

Bruce

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 28 Jul 2008 08:29:04 +0100

Hi, Bruce:
> a non-peer bootstrap server would be, actually.  

In my mind, I think there are big difference between enrollment server and bootstrap server. Enrollment server is contacted when a user first joins the p2p system, but the bootstrap server should be contacted each time the user joins the system if the boostrap server is used. Although boostrap server role could be taken by a peer, but the procedure for getting bootstrap peer from bootstrap server has different semantics from the JOIN proced
ure, so it should be handle differently. 

> OTOH, I don't 
> think 

I am not sure I understand above texts. If a JP does not know where the bootstrap server is, where will it send the JOIN message? 

Regards!

JiangXingFeng

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 28 Jul 2008 08:52:24 -0400

I might be missing the point, but I don't think Bruce is talking about
the enrollment server here at all.

The question rather is what the purpose of a bootstrap server that
isn't also a peer. If a bootstrap server is just essentially a
persistent bootstrap peer, then I think RELOAD already has this.

The question is -- do you have an interest in a server that is the
bootstrap server but *isn't* a peer, and if so, why? If not, isn't a
bootstrap server really just a bootstrap peer that happens to be up
all the time?

David (as individual)

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 28 Jul 2008 14:15:33 +0100

> bootstrap server really just a bootstrap peer that happens to be up

Right. In my mind, bootstrap server could learn enough peer information in the overlay. But maintaining accurate information about peer, for instance, online or offline, will make the bootstrap server hard to scale. So trying candidate mechanisms sequentially may be useful. Anyway, I think bootstrap peer would be listed as a candiate mechanism. Whether the bootstrap server is really used in the specific deployments is up to network operator
. 

> > In my mind, I think there are big difference between enrollment 
> server and bootstrap server. Enrollment server is contacted when a 
> user first joins the p2p system, but the bootstrap server should 
> be contacted each time the user joins the system if the boostrap 
> server is used. Although boostrap server role could be taken by a 
> peer, but the procedure for getting bootstrap peer from bootstrap 
> server has different semantics from the JOIN proced
> > I am not sure I understand above texts. If a JP does not know 
> where the bootstrap server is, where will it send the JOIN message?
> >
> >
> > Regards!
> >
> > JiangXingFeng
> >
> >

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Jul 2008 17:02:17 +0100

> bootstrap server really just a bootstrap peer that happens to be up

A bootstrap server in my vocabulary is a high-availability point of  
contact that lets you find a bootstrap peer. You then use the  
bootstrap peer to join the overlay.

A "bootstrap peer that happens to be up all the time" is a bootstrap  
server if you have a way to find it outside of the overlay protocol.  
DNS, DDNS, mDNS, WedDAV collections, etc. are example ways to find it.

--
Dean