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
