For DHTs that can route in both directions, this could work. Standard Chord can't guarantee reachability if you try to route backwards, however.
The other problem is with routing during overlay healing. If the overlay is partitioned and peer A is trying to route a message back to B through some peer C, if this message is recovering from a partition, C may not be in the same partition as B, so ultimately following a path through C may not lead to B, even if C appears to be "closer" to B. Full symmetric (or iterative) are still the most reliable routing methods for these situations. If we want to improve the routing performance, I would prefer the ability to do direct response with optional full-symmetric return if the hop-by-hop ACK on the direct response isn't received. (this option was evaluated in "Non-Transitive Connectivity and DHTs," WORLDS'05.) It's a slight increase in complexity, but it has the virtue of working in the majority of situations without any other special cases. Of course, DHTs that learn/cache on response routing might still want to specify other routing options. Bruce On Mar 6, 2008, at 10:25 AM, Jerry Yin wrote: > I saw several people pointed that the symmetric routing mechanism > used in > the reload-3 will have problems during churn. I am wondering if the > "semi-symmetric" routing protocol would solve this problem. The > protocol is > like this: > > 1. Unlike the symmetric protocol in reload-3 that each peer will > insert it's > Peer-ID in the Request messages, the semi-symmetric protocol > requires only > those peers that are interested (or required) in receiving the > response > messages insert the Peer-IDs in the via list. This works similar to > the > "Record-Route", and "Route" header in SIP protocol. > > 2. The request will route the same way as the reload-3. > 3. When a peer receives a response message, it will do following > processing: > a. Check if the top via is pointing to this peer. If yes, remove > the top > via, send the response towards the next top via in the via list > (see d). > b. If the top via is not this peer, check if this peer is > responsible for > the Peer-ID in the top via, this could happened when that peer left > the > overlay. If it is responsible for that Peer-ID, remove the top-via, > do the > same thing as a). > c. If this peer is not the peer identified or responsible for the > peer-ID > in the top via, it will do nothing about the via list, just forward > the > message towards the top-via Peer (see d) > d. When a peer sends the message towards next peer, it has two > choices. It > can forward the message directly to the peer in the top-via (DTLS), or > forward to its neighbor peer closer to the top-via Peer (TLS). This > way, > this peer don't need to create new TCP/TLS connections to the > designated > peer, but use it existing connections. > e. If a client depends on this peer, or this peer is the outbound > of other > peers, this peer always insert it's Peer-ID in the requests. This > way, it > guarantees that all the responses will go through this peer. > > > This protocol should solve the problem that the via-list broken during > churn. It also have the similar advantages as the symmetric routing. > > Just my two cents. > > Regards, > Jerry > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Behalf >> Of Bruce Lowekamp >> Sent: Wednesday, March 05, 2008 4:57 PM >> To: Bruce Lowekamp >> Cc: 'Henry Sinnreich'; 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] :Re: Extending the (inclusive) merge for P2PSIP >> >> >> >> On Mar 5, 2008, at 4:49 PM, Bruce Lowekamp wrote: >>> >>> I'd be interested in any studies that support the concern that >>> failure on the return path of a symmetrically routed message are a >>> significant issue. Generally, forward-routing is more likely to >>> fail >>> because the link may have been unused for up to the periodic >>> maintenance interval plus the timeout period. So the forward-routed >>> request may be the first message in some time to traverse the link. >>> The response, on the other hand, will arrive within whatever the >>> latency of the request/response time is, which is almost certainly >>> orders of magnitude shorter. >>> >> >> I hate responding to my own message, but just to clarify, when I used >> the word "forward" in that paragraph, I meant to refer to the steps >> of forwarding the request around the overlay to the destination >> peerID, and to distinguish that direction from the return direction. >> I did not mean to refer to forward-only routing. >> >> 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
