On Mar 5, 2008, at 3:45 PM, jiangxingfeng 36340 wrote: >> Routing replies >> actually doesn't require involvement of the DHT (although some >> DHT algorithms do >> learn/cache based on reply paths). > > I don't think so. it is the case if there is no churn in the > network. If there is churn, the reverse connection may not be > available while routing replies. One of the reason is the neighbor > peer in the connection table leaves the overlay or the connection > is broken at that moment. In this case, how does the RELOAD > process? only give up the transaction or fall back to the overlay > routing based on peer ID? >
As currently specified, the system would rely on end-to-end retransmissions to handle this failure mode. 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. Here we're getting into a much more complicated area of DHT research. DHT routing algorithms that want to maximize the success rates of individual queries can go to quite extreme lengths of having hop-by-hop retransmissions along alternate forwarding paths, fallback to iterative routing, etc. Which of these are worth doing is an interesting question. For a P2PSIP VoIP call, if the system manages churn successfully but takes 20 seconds to return the correct value, the VoIP phone has already been slammed down and the cell phone is being used anyway. Parallel lookups along alternate paths and parallel lookups for alternate replica keys (random replicas) appear to me to be better choices for a low-latency response in the presence of churn/adversaries. If we want to devote protocol complexity to better performance in the face of churn, I'm not sure it's not better spent on tuning selection of peers for the routing table or other similar improvements. The Chord-like algorithm in section 9 currently replaces each finger table entry with a "better" entry based on a periodic search. I wanted to rewrite this to give preference to a longer-lived peer that's in the right interval rather than a better numerical match (I think that idea was first in Kademlia), but didn't take the time to write that text. Godfrey's SIGCOMM06 paper argues convincingly that if the peer in your finger table dies, you should actually pick a random replacement rather than do a search for the "correct" entry. In any event, the intention of the DHT algorithm in the reload-03 draft is to be a base DHT that works and is easy to implement. There's an assumption (I'm not sure if it's explicitly in the draft or not) that an overlay with specific performance/reliability requirements, especially a global-scale overlay, may very well want a better DHT than the default one. If you want to write a DHT that supports different forms of response routing, you're right, you do need to handle that at the higher level. > On the other hand, essentially, I think, the forwarding layer > introuce flexible routing decision, not only based on the overlay > routing, but also reuse the established connection. IMHO, in order > to improve performance, some new flexible routing decision may be > developed later in a generic way like what connection table does. > We should keep the extensibility. Absolutely other DHTs will have different/more flexible/better routing algorithms. But it still has to be handled by the DHT, not the base protocol forwarding layer. Only the DHT layer knows the routing metrics (and possibly even whether the routing metric is based on < or xor distance. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
