Subject: [P2PSIP] Bootstrap peer status

From: Song Haibin <[email-masked]>
Date: Tue, 23 Dec 2008 17:38:38 +0800

Overlay configuration file has contained some bootstrap peers' information.
For the initial join of a peer, I think we should ensure the effectiveness
of the bootstrap information in the configuration file. IMO, two options
here:

(1) The administrator of the overlay has deployed some always on bootstrap
peer, the information of these bootstrap peers is included in the overlay
configuration file;

(2) The enrollment server should keep status of bootstrap peers at least
some of them, to ensure that it can always provide information of some
effective bootstrap peers

Best Regards,
Haibin
Email: [email-masked]
Skype: alexsonghw

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Dec 2008 06:10:12 -0800

At Tue, 23 Dec 2008 17:38:38 +0800,
> effective bootstrap peers

IMO, this is outside the scope of the specification.

-Ekr

---

From: "Roni Even" <[email-masked]>
Date: Tue, 23 Dec 2008 18:00:20 +0200

Hi,
>From the p2psip Charter

"The initial work will assume the existence of some enrollment process
that provides a unique user name, credentials, and an initial set of
bootstrap nodes if that is required by the protocols."

I think that bootstarp nodes are important to the solution, so option 2 is
part of the required solution.
Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rescorla
Sent: Tuesday, December 23, 2008 4:10 PM
To: Song Haibin
Cc: [email-masked]
Subject: Re: [P2PSIP] Bootstrap peer status

-Ekr

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 23 Dec 2008 11:33:02 -0500

Hi Roni,

My understanding of that part of the charter is that the base protocol
can simply assume that there exists some way for the enrollment server
to be aware of the bootstrap peers.  So we don't need to solve that
problem in the base draft.  I think this makes sense because the
process of identifying and tracking active bootstrap peers will be
very deployment specific.

With that said, if someone works up some solutions to that problem and
submits a good draft that really addresses the problem, I would be in
favor of adding it to the charter.

Bruce

---

From: Song Haibin <[email-masked]>
Date: Wed, 24 Dec 2008 10:23:53 +0800

Hi Bruce,

Various early drafts have proposed the mechanisms of bootstrap peer
discovery, e.g. draft-garcia-p2psip-dns-sd-bootstrapping-00, and
draft-matthews-p2psip-bootstrap-mechanisms-00. Even in the p2psip base draft
section 11.4, it also describes that using the cached peers or broadcast
mechanisms to find the bootstrap peers. However, the only remaining issue
here is what I mentioned in my last email that how the enrollment server
guarantees the effectiveness of the information of the bootstrap peers in
the configuration file, which is very important for the initial bootstrap
process of p2p nodes, even for the later bootstrap process when it can't
find effective bootstrap nodes with other methods.

The charter assumes the enrollment server can provide an initial set of
bootstrap nodes, but I am not sure if it assumes the effectiveness of the
bootstrap nodes. By the way, another factor that impacts the effectiveness
of the bootstrap nodes is that whether or not the bootstrap nodes are behind
NATs.

Best Regards,
Haibin

>From: Bruce Lowekamp [mailto:[email-masked]]
>Sent: Wednesday, December 24, 2008 12:33 AM
>To: Roni Even
>Cc: Eric Rescorla; Song Haibin; [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Dec 2008 23:31:42 -0800

At Wed, 24 Dec 2008 10:23:53 +0800,
> of the bootstrap nodes is that whether or not the bootstrap nodes are behind

Yes, I agree that it's important that the bootstrap nodes be both
available and publicly reachable. The question is whether the
specification needs to actually provide a mechanism for the
configuration server to determine that's the case or whether
we can assume that the operators of the system can figure out
how to do that themselves using existing IETF standards
such as SNMP. IMO, the latter approach is preferable.

-Ekr

---

From: Song Haibin <[email-masked]>
Date: Wed, 24 Dec 2008 17:34:26 +0800

Hi Ekr,

>From: Eric Rescorla [mailto:[email-masked]]
>Sent: Wednesday, December 24, 2008 3:32 PM
>To: Song Haibin
>Cc: 'Bruce Lowekamp'; 'Roni Even'; 'Eric Rescorla'; [email-masked]

I doubt whether SNMP is suitable for this purpose, or we will use some
existing methods defined in the p2p protocol for it. I would like to use the
existing p2p method for it.

Song Haibin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Dec 2008 06:42:07 -0800

At Wed, 24 Dec 2008 17:34:26 +0800,
> existing p2p method for it.

Again, I think you need to explain why you think this needs to be
standardized by the protocol.

-Ekr

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 24 Dec 2008 14:58:34 -0800

> available and publicly reachable. 

A given bootstrap node only needs to be reachable to a given joining peer - so, I don't think "publicly reachable" is a hard requirement to serve as a bootstrap peer.  That said, you likely need some bootstrap peers that are publicly reachable for overlays that are meant to be available across the Internet.  

> The question is whether the

I think there is some merit to specifying how a current bootstrap peer list can be maintained - it would also help to allow peers to volunteer to serve the bootstrap function as they join the overlay.  I think this can be specified outside of the base spec itself though. 

- Vidya

---

From: jiangxingfeng <[email-masked]>
Date: Thu, 25 Dec 2008 09:15:49 +0800

> A given bootstrap node only needs to be reachable to a given joining peer -
> so, I don't think "publicly reachable" is a hard requirement to serve as a
> bootstrap peer.  That said, you likely need some bootstrap peers that are
> publicly reachable for overlays that are meant to be available across the
> Internet.

Using proposed mechanisms in relay draft can also help a node determine whether it is reachable, even if it is behind NAT, for example, a node behind a residential gateway using uPNP-IGD to get assigned address on the public side of the gateway. 

> I think there is some merit to specifying how a current bootstrap peer list
> can be maintained - it would also help to allow peers to volunteer to serve
> the bootstrap function as they join the overlay.  I think this can be specified
> outside of the base spec itself though.

I agree. A set of bootstrap peers will change because a peer joins the overlay or leaves the overlay, or some bootstrap peers are available. I also think maintain a dynamic bootstrap peers list is useful to bootstrap reliability and reduce the burden of bootstrap peers if the list is static only by configuration. 

Regards

Jiang XingFeng

---

From: Song Haibin <[email-masked]>
Date: Fri, 26 Dec 2008 08:30:55 +0800

Hi Ekr,

>Sent: Wednesday, December 24, 2008 10:42 PM
>To: Song Haibin
>Cc: 'Eric Rescorla'; 'Bruce Lowekamp'; 'Roni Even'; [email-masked]

The effectiveness of the bootstrap peer list is an important and inevitable
issue for the bootstrap of the p2p overlay. I am not sure if we can just say
that "identifying and tracking active bootstrap peers will be very
deployment specific" as Bruce said, and ignore this issue in the protocol.
>From another point of view, I don't think it can be standardized anywhere
else other than in the p2p layer protocol.

Haibin

---

From: Song Haibin <[email-masked]>
Date: Fri, 26 Dec 2008 08:50:02 +0800

Hi all,

For this topic, perhaps we could vote in the mailing list to achieve a rough
consensus.

(1) Maintaining an effective bootstrap peer list for the overlay
configuration file is important and inevitable, and should be specified in
the base protocol draft;

(2) Specify how a current bootstrap peer list can be maintained in a
separate draft

(3) Identifying and tracking active bootstrap peers will be very deployment
specific. It is out of scope for this work group.

IMO, I would choose (1) or (2).

Best Regards,
Haibin

>From: Narayanan, Vidya [mailto:[email-masked]]
>Sent: Thursday, December 25, 2008 6:59 AM
>To: Eric Rescorla; Song Haibin
>Cc: [email-masked]
>Subject: RE: [P2PSIP] Bootstrap peer status
>
>>
so,
>I don't think "publicly reachable" is a hard requirement to serve as a
bootstrap
>peer.  That said, you likely need some bootstrap peers that are publicly
>reachable for overlays that are meant to be available across the Internet.
>
can
>be maintained - it would also help to allow peers to volunteer to serve the
>bootstrap function as they join the overlay.  I think this can be specified