Hi Bruce, thanks for the response, please see the in-line comments.
thanks Jerry > -----Original Message----- > From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 06, 2008 11:17 AM > To: Jerry Yin > Cc: 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: Re: semi-symmetric routing protocol for reload-3? > > > > For DHTs that can route in both directions, this could work. > Standard Chord can't guarantee reachability if you try to route > backwards, however. > For semi-symmetric routing, it's not necessary for the responses to travel backwards all the same peers as the requests in a reverse order. As long as the peers in the via-list are in the response path, the protocol should work for any p2p algorithm. Isn't it? > 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. > This could be a problem. Unless the symmetric routing will always use direct response, it will have the same problem. > 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
