Subject: [P2PSIP] Vague semantics in Attach method

From: JiangXingFeng <[email-masked]>
Date: Tue, 14 Oct 2008 16:44:06 +0800

Hi, all:

In the section 6.4.2.1 in RELOAD 00, there is a definition on the Attach
method: A node sends an Attach request when it wishes to establish a direct
TCP or UDP connection to another node for the purposes of sending RELOAD
messages or application layer protocol messages, such as SIP.

>From the above definition, Attach request will be terminated by a node who
has the same node-id as the destination node-id in the destination list. For
example, if peer A wants to attach to peer X whose node-id is 0x123456, then
the destination list of the Attach message should be set to the node-id
0x123456, the destination type is node; But in section 14, Attach is also
used to establish connection with the nodes which will be filled in the
sending node's finger table. In this case, the destination node should be of
a resource type and the peer who will terminate the Attach request is the
peer who is responsible for the resource id. 

So there are two kinds of peers who will terminate the Attach request. One
is the peer who has the same node-id as the destination in the destination
list. The other is the peer who is responsible for the destination (resource
type) in the destination list. 

Because Attach will negotiate the parameters for ICE procedure and establish
direct connection between the sending node and the node terminating the
request. So if in some situations, if a peer wants to Attach to a node with
the same node-id as the destination, and at the same time, the node who has
the same node-id as the destination is offline, then later the peer who is
responsible for the destination will terminate the request, but the peer is
not what the sending peer intended to attach. Finally, unnecessary ICE and
connection will be established between them. IMO, I think, in RELOAD, we
need to avoid this kind of thing happen. 

Some situations where the above error happens are listed below:
1. When a peer gets another peer-id through some methods, for example, peer
A sends a FETCH message to get the peer where bob is located. Due to some
reasons, this information may be stale, for example, bob has quit the system
ungracefully without notification to the overlay. Then A will use bob's peer
id to establish a direct connection and wants to call him. Finally, a direct
connection will be established between A and other peer than Bob. However,
the SIP signaling will detect the error and refuse the call, but it does
waste resource for the unnecessary connection. 

2. When a peer receives Update message form its neighbors, and try to attach
to the new neighbor in the routing table in the Update. It is possible that
the new neighbor is not online, so it also makes the peer establish an
incorrect neighbor connection. 

So I propose to make a few modifications to Attach method in RELOAD to make
the semantics of Attach more clear and avoid necessary connections. 

1. Add more text in Attach section on how to set the destination type in the
Attach request. resource id or node id;
2. When the responsible peer receives the Attach request, the peer will
check the destination type first. If the destination type is node id, the
peer will check whether the peer's own node id equals to the destination
node id; If they don't equal, sends a error to the sending peer and refuse
to establish connection. 

Any comments are appreciated. 

Regards!
--
Jiang XingFeng

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

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 15 Oct 2008 09:59:34 -0400

Jiang,

Thanks for looking at this in detail.

JiangXingFeng wrote:
...
> Attach request. resource id or node id;

I think this would be a good clarification.  I will try to add some more 
text here suggesting why you would route an Attach to a resource-id or 
to a node-id.

> node id; If they don't equal, sends a error to the sending peer and refuse

I think this is the correct behavior, but it's actually already 
accomplished in another way.  The general routing algorithm only 
delivers messages routed to a node-id if the node-id is an exact match 
for a particular node, as described in the third bullet of 6.1.2.1 and 
clarified in the note in that section.

Bruce

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Oct 2008 16:33:17 +0200

Hi,
I think that the text addresses mostly the case when the destination type is
a nodeId but does not say much about the behavior when the destination type
is a resourceId  or compressed which are the other allowed destination
types.
Note that a resourceId can only be the final location in a resource list

Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Lowekamp
Sent: Wednesday, October 15, 2008 4:00 PM
To: JiangXingFeng
Cc: 'P2PSIP WG'
Subject: Re: [P2PSIP] Vague semantics in Attach method

Jiang,

JiangXingFeng wrote:
...

Bruce

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 16 Oct 2008 10:26:31 +0800

Bruce:

Thanks for your clarification. 

But As proposed in bullet 6.1.2.1, If the entry is a Node-Id which is not
equal to this node, then the node MUST drop the message silently unless the
Node-Id      corresponds to a node which is directly connected to this node
(i.e., a client). 

I don't think in this case, just dropping the message silently is an
appropriate action. The sender of the Attach request needs to know what
happened, otherwise, it will retransmit the request until all
retransmissions are attempted. It's a waste of time and resource. So the
destination peer SHOULD send an error response to the sending peer.

As we know, rules in section 6.1.2 serve for all kinds of messages. So does
that mean RELOAD need to differentiate message types to take different
actions when the node-id does not equal to the peer own node-id? 

Comments? 

--

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 16 Oct 2008 07:05:24 -0400

Maybe.  But there are two reasons this can happen:

- the target node doesn't exist
- the receiving node (due to instability) isn't aware of the node existing

In the first case, an error message would produce the fastest result, as 
you suggest.  But in the second case, the periodic retransmission might 
occur after the instability is resolved and a subsequent retransmission 
would be received correctly.  In that situation, if the original 
receiving node sends an error response, the transaction is terminated 
and the originating node needs to have its own timer to retry the 
attempt if it desires.

If the originating node is using parallel routing (which is allowed by 
reload, but not specified in the base draft), then it's quite possible 
that a different branch of the query is actually returning a successful 
response.

Bruce

---

From: "Roni Even" <[email-masked]>
Date: Thu, 16 Oct 2008 13:14:51 +0200

Bruce,
In the second case the originating peer can decide if to retransmit or try
another route which may be better due to instability of the first route,
this may be like sequential routing. 

As for parallel routing, how come it is allowed in reload and not specified.
This is not a standard way for an operation mode.

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Lowekamp
Sent: Thursday, October 16, 2008 1:05 PM
To: JiangXingFeng
Cc: 'P2PSIP WG'
Subject: Re: [P2PSIP] Vague semantics in Attach method

Bruce

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 16 Oct 2008 10:16:35 -0400

> this may be like sequential routing. 

True.  That seems like something of an argument for a provisional 
response, rather than a final response to me.  Interesting question 
whether that's worthwhile.

> This is not a standard way for an operation mode.

The base protocol is intended to support it, but it's not part of the 
default overlay algorithm.  We don't want to prevent more sophisticated 
overlay algorithms from using it, however.

Bruce