Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 3 Mar 2008 12:11:30 -0500 (EST)

(sorry for multiple copies, if any)

> Well, one of the nice features about RELOAD, IMHO, is that very
> little explicit support for clients is needed. Basically, a client
> is a node which connects to other nodes but does not issue JOINs
> or UPDATEs. Therefore:

For scenarios where a node initially joins as a client and later decides [upon 
inviation from another peer] to upgrade itself to a peer, it will need a 
mechanism to obtain the routing table of its connected peer. In such a 
scenario, a client needs to issue an UPDATE.

A client may also like to maintain connections with multiple peers incase the 
peer it is connected to goes offline. Thus, it needs to send an UPDATE to 
obtain a list of backup peers from its connected peers. If a client connects to 
multiple peers, does it need to advertise multiple destination lists?

> - The peers it is explicitly connected to can route to it
>  directly.
> - It is in their neighbor table but not their route table so
>  it never routes packets.
> - Because it doesn't JOIN it never stores data.
> 
> 
> Note that a client can connect to peers at one of two places:
> 
> - At the location indicated by its peer-id.
> - At a random location.
> 
> In the first case, routing to the clients peer-id simpyly works,
> since it goes through the node responsible through that space,
> which is directly connected to the client. In the second case,
> the client can advertise a destination list [this is one use
> for this feature] consisting of the peer it is connected to
> and then itself.

As I mentioned earlier, if a client connects to N peers to mitigate against 
peer churn, it will need to advertise N destination lists similar to a 
multihomed router advertising N routes. This increases the state/message 
complexity.

Further, routing by destination lists breaks during churn.

-s

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

---

From: Salman Abdul Baset <[email-masked]>
Date: Mon, 3 Mar 2008 15:29:27 -0500 (EST)

>> For scenarios where a node initially joins as a client and later
>> decides [upon inviation from another peer] to upgrade itself to a peer, it
>> will need a mechanism to obtain the routing table of its connected peer.
>> In such a scenario, a client needs to issue an UPDATE.
>> 
>> A client may also like to maintain connections with multiple peers incase
>> the peer it is connected to goes offline. Thus, it needs to send an
>> UPDATE to obtain a list of backup peers from its connected peers. If a
>> client connects to multiple peers, does it need to advertise multiple
>> destination lists?
> 
> I'm sorry, I don't understand your argument here.
> 
> 1. You don't need do do an UPDATE to get the routing table of a
>   peer. The ROUTE-QUERY command does this.

According to the existing model, clients need to explicilty request the 
connected peer (using ROUTE-QUERY) to transfer its routing table to client in 
an UPDATE message. Is there any particular reason why a client cannot request 
the routing table directly from its connected peer?

> 2. The only case in which you need to use destination lists is
>   you're connected somewhere other than the replica set for
>   your own peer id.

This will likely be the case for unstructured overlays.

>> As I mentioned earlier, if a client connects to N peers to mitigate
>> against peer churn, it will need to advertise N destination lists similar
>> to a multihomed router advertising N routes. This increases the
>> state/message complexity.
> 
> Yeah, it only makes sense to choose a peer relay outside of your
> own replica set if you know specifically about that peer
> and know that it's stable. Otherwise, you should use one
> in your replica set.

> Well, sort of.
> The way that this works is that the client (with peer ID P) connects
> to peer X and advertises the destination list (X P). As long as X is
> reachable (no matter how much churn there is) then you should be
> reachable as well. Yes, this creates fate sharing with X.
> That's not necessarily bad.

My Skype client, when acting as a ordinary node, does not have fate sharing 
with its super node.

-s