Re: [P2PSIP] New versions of RELOAD and sip draft

[jc <julian at orchidseed.org>]

Xiao,

If a node has is not a part of the ring it is a peer otherwise it is a client. 

For simplicity I keep state of each node internally but this brings no external value. These can be determined outright by checking your connection table against your routing table as well without enumerations but brings complexity to this simple query.

/**

 * Current node klass. May be client or peer, will default to none for pre-bootstrap setup.

 */

enum {

    node_klass_none = 0,

    node_klass_client = 1,

    node_klass_peer = 2,

};

There is no possible way to determine via the base protocol if a node is a client or a peer except by the fact that it may or may not be in the ring. I handle this internally and don't feel that sending this over the wire would bring benefit. 

What you describe here would require changes to the protocol header and would be defining a first class concept for nodes.

Julian Cain

On Oct 10, 2009, at 4:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote:

Hi Cullen,

I've had a quick review of these two drafts, and still not quite clear
with some Client related issues.

I know Client is not the first-class concept in RELOAD, but as it has
been involved in the RELOAD protocol, RELOAD should give full support to
client anyhow, right?

In the terminology chapter of RELOAD Base draft, the connection table is
defined as:  
    "The set of peers to which a node is directly connected.  This
includes nodes with which Attach handshakes have  been done but which
have not sent any Updates."
although, the second sentence implies that clients are also involved in,
I still suggest to replace the "peers" in the first sentence with
"nodes" to make it more clear that both peers and clients can be
maintained in the table. 

In my opinions, connection setup and maintenance between client and its
connected peer (responsible peer or arbitrary peer) is a key issue for
client support in RELOAD.  My question is: Does a peer in RELOAD
distinguish if the connection is to a peer or to a client? Because the
reaction of the peer could be different when the connection is lost.  

As a client could set up a connection only with an arbitrary peer. Does
this peer distinguish such connection from those it is responsible to?
Should this peer inform the client's responsible peer about the
Destination List to the client? So that it can still be accessed by
other nodes. Or should the Destination List been stored with some usage,
say SIP Usage? If so, the SIP usage must be extended to allow a
Destination list containing more than one Node IDs.  In current SIP
usage draft, the SipRegistration structure only allow one address being
stored in the Destination List, as:
 " Destination          destination_list<0..2^16-1>;"
It should be replaced by: "Destination          destination_list
[dest_list_length];"  
to enable a longer list stored by arbitrary connected clients.

Anyway, IMHO, RELOAD should make sure to cover all situations a client
could meet or at least clearly distinguish issues of clients, especially
for arbitrary connected ones, which are left to be solved by other
drafts. Thanks.


Best Regards,
Xiao, Lin


-----Original Message-----
From: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] On Behalf
Of ext Cullen Jennings
Sent: Wednesday, October 07, 2009 1:53 AM
To: P2PSIP WG
Subject: [P2PSIP] New versions of RELOAD and sip draft


I just submitted
draft-ietf-p2psip-base-04
and
draft-ietf-p2psip-sip-02

These contain technical changes but do not have a lot of editorial
changes. At some point we need to go and reorganize the documents with
editorial changes.

Cullen <in my individual contributor role>

_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
P2PSIP at ietf.org
https://www.ietf.org/mailman/listinfo/p2psip