Hi vidyan, I also agree with you to give a deeper discussion and specification on RELOAD clients. IMO, all client related specification could be taken out side of BASE draft. RELOAD BASE just need give a general rule for overlay construction and common behavior of both peers and clients.
In your email below, you defined clients as nodes without routing responsibility. However, in RELOAD Base, clients was defined as nodes which have Node-ID but do not participate in routing or storage. That means, They could be nodes with routing but without storage. Three kinds of clients has been analysed in draft [draft-xiao-p2psip-client-routing-00.txt], http://www.ietf.org/internet-drafts/draft-xiao-p2psip-client-routing-00. txt. This small difference may need to be negotiate with RELOAD Base. No matter what the result will be, at least, we should discuss something basing on a same terminology, right? You recommend only a single neighbour for each client. IMO, a client can maintain more than one neighbours, but only keeps one entry in its Routing Table at a time. It not only ensures all messages from/to the client are through the OAP, but also make sure the client could be quickly hand over to a Direct Attachment Point (DAP), which can be selected directly from the neighbours, when necessary. It offers a seamless transfer from client to eclient. By the way. in my draft [draft-xiao-p2psip-client-routing-00.txt], the Routing Client and Pure Client defined there are in the scope of your client discussion with similar concern. We do need a unified protocol for Reload clients. Best Regards Lin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Narayanan, Vidya Sent: Thursday, July 02, 2009 3:18 AM To: [email protected] Subject: [P2PSIP] Client operation in RELOAD The client operation in RELOAD is currently underspecified and cannot be implemented based on the spec. Here are the procedures that need to be specified to support client behavior with attachment at the identity owner. For attachment at any other arbitrary point, a lot more thought needs to be put in to ensure support for mobility and stability of operation. My suggestion is that it is better left outside the scope of this draft and defined separately. In this case, RELOAD will only support attachment at the identity owner, which seems very reasonable. Message changes necessary to support clients: --------------------------------------------- We need to introduce a "Node Type" in the JOIN Request message that indicates that the joining node wishes to do so as a client. Also, Update messages need to have a "case clients" and the "case full" needs to include client information. I suggest adding a section on clients - suggested text below: Clients: -------- Clients are nodes that may provide and receive services in an overlay without participating in overlay routing or incurring the same amount of maintenance overhead as the overlay peers. Clients are modeled as close to peers as possible in terms of overlay functionality. In order to allow these nodes to participate in the overlay without inherently being a routing member of the overlay, some changes are required to the join process and the manner in which neighbor relationships are handled for such nodes. However, all other procedures (e.g., data management using STORE, FETCH, etc.) are handled in exactly the same way as for any other peer in the overlay. We denote the point of attachment of the Non-Routing Peer on to the overlay as Overlay Attachment Point (OAP). The peer responsible for the node ID of the client provides the OAP functionality. This allows the integration of clients into the architecture with the least deviation from the peer. Hence, any node that wishes to be a client finds the node that owns its identity space and attaches to it. By definition, any node serving as a peer in the overlay MUST provide the OAP functionality as well. The mode of using a different node as the OAP may be allowed as an extension to this protocol - this can be done for availability or load balancing reasons, for instance. Clients obtain overlay node identities just like peers do. Hence, the enrollment server may be completely unaware of the distinction between a peer and a client. By virtue of this, the enrollment procedure is identical for peers and clients. The join procedure is somewhat simplified for a client and the section below describes that process. All data management operations to/from a client are indistinguishable from those of a peer. The main difference between a client and a peer is that a client only has a single neighbor in the overlay, i.e., the OAP. The client routes all messages through the OAP - i.e., it has a default route with the OAP as next hop that is used for all messages. The OAP has the client as a neighbor and has it in its routing table. None of the nodes in the overlay except the OAP are aware of the presence of the client. The messages to/from a client are natively routed on the overlay. All messages that are sent to the client arrive at the OAP by regular overlay routing (since it owns the identity space that includes that of the client). The OAP then looks up its routing table to route the message to the client. The OAP may make use of the presence of a client to offload some of its storage responsibilities or to replicate data stored at it. This may be mutually beneficial in some cases - e.g., the client may be limited in terms of bandwidth and battery, while the OAP may be limited in memory. However, this is out of scope for this document itself and any such storage sharing that occurs between a client and OAP is not visible to the rest of the overlay. Hence, any such thing must be managed out of band between the OAP and the client. Client Bootstrap Process: ------------------------- A client obtains a list of bootstrap peers from the enrollment server as any other node in the overlay. The client triggers the join process the same way as a peer does. But, the process is a bit more abridged than for a normal peer. It is described below: 1. Client connects to its chosen bootstrap node. The client MUST form a TLS session with the bootstrap node, using the certificate or PSK required for overlay membership. 2. The client sends a Join request message to its own Node-ID c, through the BP. The Join Request message indicates that the joining entity is a client (with Node Type being set to Client). This is routed to the admitting peer (AP). The AP sends a response to the Join, after noting that it must serve as the OAP. 3. The client also sends an Attach request message to c through the BP. This may be sent in parallel with the Join message. The AP sends an Attach response, resulting in connection establishment between the client and AP. At this point, the AP has the client included in its routing and connection tables and the client has established a default route through the AP. The join process is now complete. The OAP MUST NOT send any Update messages to other peers in the overlay as a result of a client joining the overlay. The OAP simply updates its routing and connection tables with the client information. The client does the same. The OAP may, however, follow up the join process with a series of STORE request messages to transfer some data it stores to the client. Impact of Churn on Clients: ---------------------------- As the ownership of the overlay identity space changes, the clients may be affected. For instance, if the OAP to which a client is attached leaves the overlay or fails, the client needs to find the appropriate OAP to attach to. Also, when the identity ownership changes due to a new peer attaching between the OAP and the client in the identity space, the client needs to use the new peer as its OAP. Essentially, the need to change OAP may arise from one of the following three conditions: * A new peer joined the overlay with an identity that lies between the identities of a client and its OAP * The OAP of a client performs a graceful leave from the overlay * The OAP of a client abruptly leaves the overlay or fails These three cases are explained below. Handling New Peers: ------------------- Consider the case where a client (C1) is attached to an OAP (OAP1). A new peer, P, attaches to the overlay, with an identity that falls between C1's and OAP1's identity. P is now responsible for the identity that belongs to C1 and hence needs to serve as the OAP to C1 (say, OAP2). When P completes its Join process, OAP1 detects that it no longer owns the identity corresponding to C1. OAP1 now sends an Update message to C1, indicating that it has a new neighbor. The Update message provides information about P to C1. Upon receiving the Update message, C1 sends a Join Request via OAP1 to P. The difference between this JOIN process and the regular one is that C1 can perform this Join via OAP1 instead of finding a bootstrap peer to perform the join through. Since P is part of the overlay and is OAP1's neighbor, OAP1 can reach P directly, thereby greatly reducing the number of hops the Join messages need to traverse. Once the new Join process completes, P takes over as C1' s OAP (OAP2). C1 may send a Leave Request to OAP1 subsequent to its attachment to OAP2 - this will trigger cleaning up of state corresponding to C1 at OAP1. If OAP1 stored any of its data at C1, C1 must transfer that back to OAP1 before joining again with OAP2. The mechanism to handle this is out of scope of this specification. When a change in the identity space ownership causes the OAP of a particular node to change, the present OAP MUST send an Update message to the client, indicating that it has a new neighbor. Upon receiving the update message, the client MUST send a Join message to the new OAP - this JOIN message can be routed through its current OAP. The client SHOULD send a Leave request to its old OAP, once it has successfully attached to the new OAP. Graceful Leave of an OAP: ------------------------- When an OAP gracefully leaves an overlay, it typically sends a LEAVE request message to all its neighbors. In addition, the OAP SHOULD send a Leave Request message to the client. Further, the OAP SHOULD also send an Update message to the client, containing information about its successor, which will be the new OAP for the client. When the client receives such an Update Request, it MUST send a Join Request message to its new OAP. If the old OAP is able to assist in the Join process, the Join messages can traverse through it to set up the connection between the client and its new OAP. However, if the old OAP leaves the overlay prior to that process, the client needs to find a bootstrap peer and route its Join Request message through that peer to its new OAP, in which case, the procedure becomes similar to the failure of an OAP case described below. Failure of an OAP: ------------------ An abrupt leave or a failure of an OAP implies that there is no active messaging from the OAP to its clients indicating that an OAP change is required. In this case, the client will detect the absence of its OAP due to a timeout indicating that the OAP is unreachable. The client then needs to perform the Join process via a bootstrap peer in the overlay to find its new OAP. Impact on attach messages: --------------------------- There is an issue that nodes may send attach messages to the client's node id when looking for a finger. The client needs to reject such Attach requests coming to it. However, the client will be unable to distinguish Attach messages that are being sent to it to really set up an end-to-end connection for other purposes. We may want to consider introducing a "purpose" in the Attach request messages that indicate the reason for the Attach. This will make it possible for the client to reject a request that is sent to establish a finger. The node sending the Attach request can then slightly alter the resource id to issue another request. Thanks, Vidya _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
