JiangXingFeng wrote:
4. In section 3.3.1, some routing alternatives are listed. As for
direct
response and relay peer, I think they could be well used together
with the
symmetric routing proposed in RELOAD-04 although there are some
limits with
their use. For example, the original peer could convey its contact
address
and/or the chosen relay peer information to the destination in the
request,
it's
up to the destination peer to choose whether send the response in
all ways
or
only in a subset of ways. In this way, they could bring enhancement
to the
symmetric routing.
As for routing in the overlay, my major concern is still the
stablity of the
reverse connection due to the churn. In my mind, symmetric routing
works
better
where the hops for the request is not big and direct response and
relay peer
could provide much help when the hops is big. I've done a few work on
comparing
different routing modes listed in RELOAD-4 which has not finished
yet. If
some
data comes out, I will share them with the community.
I suspect this is an important topic worth of it's own thread. I look
forward to seeing your work and I hope this is the sort of thing we
end up getting time in the WG meetings to talk about because it is
important. My main concern with all these is that the routing works
well enough that two partitioned networks that each have a ring can
successfully merge back together. Any scheme where that does not
allow this would seem somewhat broken to me.
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.
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). 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.
Now if you work in a world where NATs and firewalls don't exist, the
world would be different, of course.
Bruce
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
