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 PROTECTED] [mailto:[EMAIL PROTECTED] 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 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 JiangXingFeng wrote: > 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? > > -- >> Jiang, >> >> Thanks for looking at this in detail. >> >> JiangXingFeng wrote: >> ... >>> 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; >> 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. >> >>> 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. >> 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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
