My initial thoughts are pretty similar to Bruce's but more
importantly, I think routing is one of the things we need to hash out
as a WG and figure out what is best. I'm imagining a WG meeting where
we had a few people talk about the various possibilities, the pros and
cons of them, then made a sound engineering choice. I really look
forward to meetings like that - designing the RELOAD as an individual
draft is like working in a vacuum, which is fine other than you blood
boils and your head explodes.
One general strategy the authors have been taking is keep the base
protocol having the simplest of possible solutions but make sure that
one could allow extensions that allow better performance. The type of
suggestion you are talking about here of forking responses so they are
sent back on both a symmetric and direct path seems like something
that could be added as extension. There be a lot of things to consider
such as how much it improved the situation, congestion control, and
the security issues around it contributing to DOS attacks - typically
it is nice to design things to they don't have message amplification
but perhaps there would be some way to mitigate that in the scheme you
proposed.
Cullen <with my individual contributor hat on>
On Jun 20, 2008, at 9:11 AM, Bruce Lowekamp wrote:
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
