I think peers can connect in the same ways as clients.
On Oct 26, 2009, at 7:18 , Xiao, Lin (NSN - CN/Beijing) wrote:
Hi Julian,
You are right. But it's Client Routing for clients, right? A peer,
however, can not attaches arbitrarily on the overlay. That is the
exact
difference between peers and clients in my previous e-mails. If what
you
mean is that peers can also been found by algrithm 2 when it lost its
position in the overlay, the overlay would be messed up with
disordered
topology structure finally.
Br
Lin
-----Original Message-----
From: ext jc [mailto:[email protected]]
Sent: Saturday, October 24, 2009 8:08 AM
To: [email protected]
Cc: Xiao, Lin (NSN - CN/Beijing); [email protected]; [email protected]
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft
In section 3.2.1. Client Routing contains two algorithms for Client
routing. if you choose either of those algorithms then this won't be a
problem.
The first algorithm would forward through 500 around to 600(a direct
connection).
The second would use the destination list and form the route to 600 by
storing information in the hash table.
Finally, it is up to the Topology Plugin to ultimately handle this
which
Chord does so fine under this condition via it's own update
(stabilization) procedures.
Julian
On Oct 23, 2009, at 3:47 PM, [email protected] wrote:
IMHO Lin Xiao has a quite valid point. If due changes of topology,
node 500 permanently loose its ability to interconnect with close
( in
DHT space) nodes, it has to be excluded from DHT ring or have to
get a
new ID.
Otherwise, it will became a permanent dead-end node for lookups for
targets in its immediate neighborhood that significantly degrades
speed of DHT lookup and ( under some conditions) can event result in
DHT space segmentation.
500 can of course keep it's node id, regardless of whether 400 and/
or
600 are there or not. Due to stabilization and by means of the
successorcache the predecessor of 400 will notice the absence and
bridge directly to 500 as well as 500 will skip 600 after a short
time and go to 700 (in order to stay in the picture). Using notify
the ring will close again. 400 and 600 may return whenever they
want.
Regards
Xiao, Lin (NSN - CN/Beijing) schrieb:
Hi,
Maybe I'm wrong, but I consider peers in RELOAD are structured with
a DHT algorithm, e.g., in Chord, peer with Node-ID 500 is connected
with peer 400 and 600.
However, what will happen, if peer 500 totally lose both of the
connections due to mobility and NAT, but can set up new ones with
peer 100 and peer 300? IMHO, in order to keep the topology
structured, if this node still want to be a peer in the overlay it
should change its Node ID to, say 200, and rejoin the overlay to
enable itself still reachable with the DHT algorithm.
If peers in a overlay can not be connected with a strict order, the
DHT algorithm for structured topology will not work anymore.
Br
Xiao, Lin
-----Original Message-----
From: ext jc [mailto:[email protected]]
Sent: Thursday, October 22, 2009 12:41 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Cullen Jennings; P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft
The draft doesn't state that you MUST change you NodeID if you lose
overlay connectivity. In fact under your given condition you would
simply retain it and connect again as a Client when the network is
back up.
Julian
On Oct 21, 2009, at 3:59 AM, Xiao, Lin (NSN - CN/Beijing) wrote:
Hi Cullen,
Thanks for your reply.
I agree that RELOAD have covered most of the functionalities of
peers
and clients. However, there is still a little different between
clients and peers while connection is lost besides data replica.
What
I mean here is the Node ID.
Because all the peers in the overlay are connected according to a
strict overlay algorithm. The position of a peer in the overlay is
decided by its Node ID. If a peer lost its position
(disconnected) in
the overlay because of moving and NAT, but still want to work as a
peer, it must change its Node ID, which means it need do the
enrollment again and rejoin the overlay.
But, because a client can attach with an arbitrary peer. It is not
necessary for a client to change its Node ID when it change its
attaching peer. The most important thing here is that, this
behavior make it possible for a client to keep session continuity
while its attaching peer is switched.
Considering to deploy RELOAD in reality, stable nodes are
preferred to work as peers while mobile nodes can take the
advantage of the client behavior mentioned above. Sessions can be
kept with high mobility, as unique Node ID is maintained by
clients. I'm not sure if RELOAD has considered this distinction of
client, which help clients to be attached with the ovelay as long
as it can build at least one connection to the overlay.
Br
Xiao, Lin
-----Original Message-----
From: ext Cullen Jennings [mailto:[email protected]]
Sent: Friday, October 16, 2009 9:05 AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: P2PSIP WG
Subject: Re: [P2PSIP] New versions of RELOAD and sip draft
Thank you, few comments inline....
On Oct 10, 2009, at 2: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.
I agree. I changed this - thank you for the careful review to
catch
things like this.
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.
Reload does distinguish at some level but what do you think a node
needs to do differently when a connection is lost if the
connection
when to a peer or client. Clearly how data replication is handled
and some of the finger table stuff is handled differently but I
think that
is covered in the draft. If you see something specific missing,
let
me
know.
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?
I don't se the need 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?
Yes, that is the approach to store destination lists where they
are
needed.
If so, the SIP usage must be extended to allow a Destination list
containing more than one Node IDs.
agree that it needs to allow storing multiple Node IDs but I think
it already does that.
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>;"
The destination_list here is an array of Destinations so it allows
between 0 and 65K entries in the array. I agree the syntax for
specifying arrays might seem a bit weird but I think the structure
is what you are pointing out we need to have.
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: [email protected] [mailto:[email protected]] 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
[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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
