jiangxingfeng 36340 wrote:
As for partition, what I see the peer could do after he knows that is to
restart a join-like operation. The direct response and relay peer work in
the partition situation in the same way as in other situations. Am I missing
something?
You're right in that they work just as well as they do any other
time---when they work they work fine, but if they don't work (due to NAT
filtering, etc), you still need the fallback to symmetric routing.
It seems that symmetric routing could work in all cases. In chord algorithm, if
the number of the nodes in the system above 1000, the possible largest hops for
a request would be larger than 10 hops. IMO, symmetric routing will have lower
success rate as the number of hops increases, although I have no real data to
support my concern. On the other hand, the data to be looked up is distributed
around the overlay, so the number of hops will h
ave an appropriate even distribution within (0, log(N)]. Are you sure symmetric routing could work well if the request need traverse long hops? Are you sure the end-2-end retransmission mechanism could make the transaction successful in the end?
The question comes down to whether the return path is likely to fail
over the interval of the response latency.
But before you answer that question, you have to consider whether the
outbound path is likely to work. That depends on the churn rate of the
overlay and the refresh/keepalive rate used by the peers. Regardless of
the answer to those questions, the response latency of the return path
is going to be lower than the keepalive rate*. Therefore the outbound
path is more likely to fail than the return path.
From my survey of the literature, nearly all sources suggest that if
the churn rate is sufficiently high that the outbound query is likely to
be lost, the best solution is to fall back to iterative routing so that
the querying peer can ensure that at least some progress is made in
resolving the query.
So my answer to your question is that if the combination of churn rate,
path length, and path latency is high enough that symmetric routing is
likely to fail, you would already be having problems with recursive
forwarding of requests regardless of the return method being used.
*I've seen some work on using incredibly fast keepalive timers to try to
improve overlay stability. I'm not convinced that the benefits of
building an overlay with unstable peers is worth the benefit. I would
much rather use an overlay algorithm that is more careful in selecting
which nodes can serve as peers.
What I suggest is to integrate symmetric routing mode, direct response,
relay peer into an integral routing mechanism and could work more efficient
than using a single candidate mechanism.
The decision the WG will have to make is whether the complexity of
additional routing mechanisms is worth the increased performance
(removing a few hops on the return path).
The benefit to me from direct response and relay peer alternatives is not only removing a few hops. The more important one is to improve the success rate of the transaction if the request need to be traversed with large hops.
We tried to apply Occam's
Razor rather aggressively in evaluating features, and adding additional
complexity to the protocol for these features seemed a bit questionable,
at least for right now.
I don't see other alternatives introduce too much complexity. The simplest way
to integrate the three routing mechanisms is: the original peer carries the
relay peer and local interface address information in the request and sends the
request; the intermediate peers record the via-list. When the destination
receives the request, it could compute how many hops the request traversed. If
the number of hops is large, it not only returns the res
ponse by using the symmetric routing, but also sends the response by using the direct response or relay peer respectively.
I'm not suggesting that this is monumentally complex (actually, I think
locating a relay peer is very complex and needs a standalone draft).
Merely that I think the WG needs to look at what the requirements for
the protocol are and where it is worth adding additional
complexity/message size. This particular issue imposes some additional
message size and some additional processing on the part of the
responder, but it is merely one of quite a few such issues.
Bruce
Now if you work in a world where NATs and firewalls don't exist, the
world would be different, of course.
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
