Subject: [P2PSIP] Routing mode in P2PSIP

From: JiangXingFeng <[email-masked]>
Date: Tue, 20 Nov 2007 18:27:51 +0800

Hi, 

There are four routing mode described in the draft-bryan-p2psip-reload-01.
After reading P2PP and RELOAD revision 2, only the iterative routing mode
and recursive mode are supported. 

Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO,
semi-recursive mode at least has two following advantages over other routing
mode:
1. Semi-recursive mode is more resilient from failures of intermediate peers
than recursive mode. In recursive mode, if any of the intermediate peers
fails, the response could not return back in the reverse path the request
has traversed. 
2. Semi-recursive mode has lower latency than recursive and iterative mode.
The response in semi-recursive mode could go back to the request originator
by forwarding based on its transport address.

IMHO, the major issue that semi-recursive mode should face is how the
response goes to the request originator if the request originator is behind
NAT. I think there must be solution to this issue. 

Comments? 

--
Jiang XingFeng

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 20 Nov 2007 07:09:27 -0500

> by forwarding based on its transport address.

These two statements are both true if the requesting peer is not
behind a NAT or a firewall.  The reload-01 protocol embedded a
"default" IP addr that could be contacted directly and then specified
how to make things work if the default wasn't accessible (NAT or
firewall problem).  The problem with that approach is that it takes a
lot longer when the default doesn't work, because you have to let it
timeout before you realize it won't work.

> NAT. I think there must be solution to this issue.

Yes, the solution is to use recursive routing.  If somehow a peer can
learn that an incoming response won't be blocked (it knows it has no
NAT or firewall, or the NAT or firewall does address independent
mapping and filtering) then semi-recursive would work.  Maybe it's
worth extending the protocol to support that, but it isn't clear it
would work and would complicate the protocol tremendously.
(Minimally, it adds state at the responder to notice that its response
must have been lost and to route it recursively instead.)

Having the responder do ICE to open a direct connection for the
response isn't really feasible because ICE would take longer than the
recursive response.

There is another optimization to allow the two peers to open a direct
connection with ICE if they're going to be sending a lot of messages
back and forth.   That's the one I would pick to improve performance
of message routing.

Bruce

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 21 Nov 2007 10:40:53 +0800

Hi, Bruce: 
Response is inline. 

Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce
> Lowekamp
> Sent: Tuesday, November 20, 2007 8:09 PM
> To: JiangXingFeng
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Routing mode in P2PSIP
> 
> Yes, the solution is to use recursive routing.  
I have some idea about this issue: how does the responder send the response
back to the source peer directly if the source peer is behind NAT? I present
it here and ask for your comments.

Maybe we could choose some peers which are on the public Internet and the
responder could ask them to relay the response to the source peer. Because
the chosen relaying peer is on the public internet, so the response could
arrive at these relaying peer. So the problem is reduced to how the relaying
peer knows how to relay the response to the source peer. IMHO, there are two
candidate solutions:
1. The source peer could find in its routing states some neighbor peers with
public address. Since the source peer and the relaying peer are neighbors,
so there must be at least a pre-established connection between them. So if
the relaying peer receives the response from the responder, it will check
whether it has a pre-established connection with the source peer. if there
is, forward the response over the connection. If there is none, maybe it
discards the response for security consideration. It is like what the TURN
does. TURN relays the packet from the peer only if there is permission for
the peer. 
2. If there is no such neighbor peers in its routing states, the source peer
could use an alternative method. It could find a public peer and send the
request to this peer. Upon receiving the request, the public peer could
learn the source transport address of the request and put it in the request.
Later the request will be processed by the responder and the response will
be returned to the public relaying peer. The relaying peer could check
whether the source peer's transport address in the response, if it is, the
public relaying peer uses this transport address to forward the response to
the source peer. 

Hope to get some comments from you and the community. Thanks in advance. 

>If somehow a peer can
> mapping and filtering) then semi-recursive would work. 
I think it is easy to know whether a peer is behind NAT or not. We could
achieve this by encoding it in the info describing the characteristic of the
source peer, such as transport address, etc. It is easy for the destination
peer to get this information and send it back directly. 

> Maybe it's
Maybe you are right. It is not easy for the responder to make sure that the
response has been arrived at the source peer reliability. But could you
share with me how the recursive mode achieves this goal? IMHO, the state is
also unavoidable in recursive mode if you realize it by keeping state at
intermediate peer. 

> response isn't really feasible because ICE would take longer than the
It is not a right time to use ICE, because the response has not returned to
the source peer, and then the source peer has not got the destination peer's
candidates.

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 21 Nov 2007 08:16:48 -0500

> peer knows how to relay the response to the source peer. IMHO, there are two

This idea works fine if a significant number of the peers have
unfirewalled, public addresses, but one of the goals of reload-02 (as
well as reload-01, asp, and most of the other proposals) is to work in
an environment where there are few to none of the peers with such
addresses.  While I understand your desire to improve routing
efficiency, if it makes the routing protocol more complicated because
different things are done in different conditions, I would be opposed
to it.  It's also very important, I think, to ensure that the load on
every peer is as equal as it can be.  Recursive routing does that for
the peer protocol.

> peer to get this information and send it back directly.

The recipient of a message can know whether the sending peer was
behind a NAT, but a peer itself can't necessarily know if it's behind
a NAT (until it talks with a node that is outside its NAT).  Detecting
that you're behind a firewall is even harder.  It can be done, but I
would hate to base a protocol on its success.

> also unavoidable in recursive mode if you realize it by keeping state at

The reload-02 messages keep the state in the message itself (the
via/route list).  Retransmission is handled end-to-end.  So the
responder still doesn't have a way of knowing for sure if the response
got back, but it can assume that it was just random packet loss and
keep sending the response whenever it gets a retransmission until the
sender receives it.  If you try to send it back directly, the
responder has to have some heuristic like if it sends the response
back twice and then receives a third retransmission, there must be a
nat or firewall issue.

Bruce

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 22 Nov 2007 10:40:31 +0800

HI, Bruce:

Response inline.

The reason why I want to introduce semi-recursive routing mode is that it
has some advantages over other routing mode and it is has the best routing
efficiency. And I also think it could be complementary with the iterative
routing mode and iterative mode. 

I also admit there are some problems in semi-recursive mode, but there are
also some other problems to be solved in other routing mode. Now, I think it
is not the right time to exclude the semi-recursive routing mode.

I also want to get some advice and comments from the other guys in the
community. 

Regards!
JiangXingFeng
> addresses. 

Sorry, I have not read the reload-02 entirely. And I will go on reading it.
I have a concern here: how does the RELOAD support the situation where all
the peers are behind NAT? How do the peers who are behind NAT, maybe
p2p-unfriendly NAT, communicate with each other? Could you give more details
here? Thanks!

> While I understand your desire to improve routing
> to it.

I don't think introducing semi-recursive routing mode will make the routing
protocol more complicated. There are two routing mode, iterative mode and
recursive mode proposed in RELOAD-2. They have different processing routine,
so the things to be done must be different in the two routing modes.
Semi-recursive could have a separate one, I think. 

> It's also very important, I think, to ensure that the load on

IMHO, if there must be some relays for communication between peers, it could
use external relay servers outside of the overlay, and I also think it could
use the peers who could help. I think the essence of the P2P technology is
helping each other. 
> a NAT (until it talks with a node that is outside its NAT).  

I am not an expert of NAT. but I know there are some methods for a node to
know whether it is behind NAT or not. STUN is an example. Do I leave
something behind? 

>Detecting
> that you're behind a firewall is even harder. 

Yes, I agree.

> It can be done, but I would hate to base a protocol on its success.

If the peer does not know where it is, behind NAT or not, does it mean the
ICE should be used even if the two public guys wants to communicate with
each other directly. From my point of view, it is time-consuming and
unnecessary. 
> via/route list).  

Could you ensure when the response is forward back on the reverse path, all
peers in via or route list did not fail or leave the overlay simultaneously?
IMHO, if any one in the list fails or leaves the overlay, the recursive
routing will fail. We should consider churn in P2P network while designing
peer protocol, after all churn is nature of P2P network.

>Retransmission is handled end-to-end.  So the
> sender receives it. 

Due to the same reason as above, we should consider the possible loss from
overlay churn, not only just assume it is a random packet loss. 

There is another issue I am also interested: how do the RELOAD-2 determine
the end-to-end timeout period? 

> If you try to send it back directly, the

To be honest, I am not totally understood. Could you give more explanations?
Thanks!

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Fri, 23 Nov 2007 10:29:54 -0500

> p2p-unfriendly NAT, communicate with each other? Could you give more details

"All" peers behind NATs does require some sort of publicly available
bootstrap server (although that can be a peer behind a NAT with
address independent mapping and filtering).  After the initial
bootstrap, most communication is routed across the overlay.

To open a new connection (for a fingertable entry, for example), any
pair of peers except those where both are behind evil (symmetric) NATs
will be able to open that connection using ICE.  If they are both
behind evil NATs, for any fingertable entry (in chord), you can pretty
much just ignore the failure because those neighbors exist just as an
optimization.   But you really do need to have a connection with your
predecessor and successor.  reload-02 proposes a mechanism for
identifying a turn server that peers could use to establish
connectivity in that situation.  But we anticipate that, even with all
peers behind NATs, both peers being behind evil NATs will be extremely
rare.

The turn location mechanism in reload-02 hypothesizes that it will be
easy to determine the percentage of peers that can serve as turn
servers.   I should also mention that we need to add some text on
letting peers behind good NATs be turn servers as well---even if you
need to use ICE to open a connection with the turn server itself,
there's no reason every peer behind a good NAT can't be a turn server.
 That essentially lets almost all peers be turn servers.

> Semi-recursive could have a separate one, I think.

Iterative and symmetric both work in the presence of NATs.
semi-recursive really doesn't without some help and a fallback on
symmetric recursive (see my response at the bottom).

> know whether it is behind NAT or not. STUN is an example. Do I leave

If you're configured with a stun server on the other side of a nat or
you communicate with a peer on the other side of a nat, then you know
you're behind one.  However, you can't ever prove that you're not
behind a NAT.  (could be on a NATed network that's using public-range
IP addresses and you just happen not to have talked with anyone on the
other side.  Or you could be on a large private network in the private
address range that doesn't have any connectivity with the outside, in
which case you're not behind a NAT.)

> each other directly. From my point of view, it is time-consuming and

I agree there are some optimizations that can be made there.  ICE has
the virtue of working, even if it's not the most efficient.

> overlay churn, not only just assume it is a random packet loss.

Regular end-to-end retransmission should handle this.  If you have an
overlay that has so much churn that you can't get a message routed
round-trip, you're going to have problems with any routing algorithm.
(and I'm not trying to trivialize the complexity of dealing with
churn.  it's really hard, but if your peers detect a failed link
quickly, symmetric recursive works about as well as anything)

> the end-to-end timeout period?

reload-02 proposes to use the standard sip timeout scheme.

> To be honest, I am not totally understood. Could you give more explanations?

To implement semi-recursive, you need to make the link-layer protocol
a bit more complex.   If you have an ack go between the querying peer
and the answering peer after the final response is received, then the
answering peer knows the response was received.  If no ack is
received, then you need the answering peer to do something else, like
return the response along the reverse path when it receives a first or
second retransmission of the original request.

Bruce

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Nov 2007 10:56:05 -0800

Hi - I'm not sure I understand what you mean by semi-recursive and  
how it would work. Could you explain a bit how it works and what  
would be needed in reload to support it. I'm always curios about how  
a node decides what to do when there are multiple options available  
to it.

Thanks, Cullen <with my individual controbutor hat on>

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 24 Nov 2007 10:20:45 +0800

>  That essentially lets almost all peers be turn servers.

What I really am very interested in: How are the peers with good property
learned? By itself or by others? 

> symmetric recursive (see my response at the bottom).

Semi-recursive may fail. It also falls back to a asymmetric method proposed
in SEP, which you could find at
http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt;

IMHO, iterative also may not work without help from other method. If the
source peer gets the next hop peer, with which there is no direct
connection. It may use the peer ID of next hop peer to arrive at the next
hop peer.  

> which case you're not behind a NAT.)

I agree with you that the location of the stun server will influence the
determination. But I think a stun server deployed on the public internet
could achieve this goal. 

> quickly, symmetric recursive works about as well as anything)

Yes, I assume the churn rate may be low. But it does exist. Let's show an
example if there is one peer in the route list which failed or leaved while
the response goes back. Say the request starts from the A, and traverse B, C
and D, and finally arrive at the destination X. If the peer C fails before
the response reaches it. So the D should route the response based on the
peer ID C. Later a peer Y who is responsible for the key C and send the
response based on B. But there is no matched connection, so X has to route
the response through the overlay. and B receives the response and forward it
to the A. 

>From the above example, the response has to be routed through the overlay
two more cycles and introduce the more latency. And it becomes worse, if the
packet is of big size. 

> reload-02 proposes to use the standard sip timeout scheme.

I am not familiar with the sip timeout scheme. Intuitively, I think it would
be more complicated than in sip because the latency may vary largely between
different transactions.  

> second retransmission of the original request.

IMHO, maybe the asymmetric is the better choice by considering routing
efficiency. There may be several relaying peers which could be tried
sequentially. 

Regards!

JiangXingFeng

---

From: JiangXingFeng <[email-masked]>
Date: Sat, 24 Nov 2007 11:04:53 +0800

Hi,
Thanks for your response. See inline. 

What I really suggest is to include the semi-recursive in the list of the
candidate routing mode due to its advantages over other methods. Of course,
there are some issues of the semi-recursive routing mode to be solved. After
we come to the consensus that the semi-recursive is useful to peer protocol,
we could start to figure out how it realizes. 

Regards!
--
Jiang XingFeng

> would be needed in reload to support it.

I give short answer here. For more details, please refer to
http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt; thanks! 

I have some ideas about this issue: how does the responder send the response
back to the source peer directly if the source peer is behind NAT?
 
Maybe we could choose some peers which are on the public Internet or behind
good NAT (endpoint-independent mapping and filtering) and the responder
could ask them to relay the response to the source peer. Because the chosen
relaying peers are on the public internet or behind good NAT, so the
response could arrive at these relaying peers. So the problem is reduced to
how the relaying peer knows how to relay the response to the source peer.
IMHO, there are two candidate solutions:
1. The source peer could find in its routing states some neighbor peers with
public address. Since the source peer and the relaying peer are neighbors,
so there must be at least a pre-established connection between them. So if
the relaying peer receives the response from the responder, it will check
whether it has a pre-established connection with the source peer. If there
is, forward the response over the connection. If there is none, maybe it
discards the response for security consideration. It is like what the TURN
does. TURN relays the packet from the peer only if there is permission for
the peer. 
2. If there is no such neighbor peers in its routing states, the source peer
could use an alternative method. It could find a public peer and send the
request to this peer. Upon receiving the request, the public peer could
learn the source transport address of the request and put it in the request.
Later the request will be processed by the responder and the response will
be returned to the relaying peer. The relaying peer could check whether the
source peer's transport address in the response, if it is, the public
relaying peer uses this transport address to forward the response to the
source peer.

> I'm always curios about how
Do you mean what the responder does when there are several relaying peers
available? If my understanding is right, the responder could send the
response parallelly for the reliability of the response;

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Nov 2007 08:17:17 -0800

At Sat, 24 Nov 2007 11:04:53 +0800,
JiangXingFeng wrote:
> could ask them to relay the response to the source peer.

Discovering for sure whether you're one of these peers seems somewhat
difficult. And then we're faced with the problem of advertising the
existence of such peers. That seems like something it would be better
not to have as a precondition of success.

-Ekr

---

From: Song Yongchao <[email-masked]>
Date: Mon, 26 Nov 2007 10:21:03 +0800

[Jiang]> > Maybe we could choose some peers which are on the public Internet
or behind
> > could ask them to relay the response to the source peer.
[Eric]> Discovering for sure whether you're one of these peers seems
somewhat
> difficult.

Eric, could you explain for me why do you think it is difficult to discover
that? I am a little confused about whether each peer should have a knowledge
of that it is NATed or not, and know its NAT Mapping address or public
address or TURN relay address, to set up a direct connection with other
peers?

Best Regards!
Song Yongchao

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Nov 2007 18:26:58 -0800

At Mon, 26 Nov 2007 10:21:03 +0800,
Song Yongchao wrote:
> that?

How do you propose to discover it? It's certainly not enough to have
a non-1597 address. Those are still sometimes NATed. You can compare
your host candidate to whatever server reflexive candidates you have,
but if you're unlucky about STUN server selection, they might still
be the same. This complexity is part of why ICE does not attempt
to make such determinations.

-Ekr

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 26 Nov 2007 10:41:56 +0800

Hi, Eric:
Thanks for your response. I agree with you that semi-recursive mode has a
few issues you have pointed out. I also think it could be solved as the
research deepens. 

What I concerns about the recursive mode is its routing efficiency. Using a
peer ID to route packet could at least ensure in theory that NAT isn't a
problem any more. But latency in recursive for the transaction appears to
vary dramastically. It brings the prediction of end-to-end retransmission
timeout harder. If the timeout value is set inappropriately, either a lot of
retransmission packets go into the overlay or transaction stands with higher
latency. 

Some overlay maintenance operations like Join, Leave, may be insensitive to
the routing efficiency. What they want is the reliability and correctness.
But some other operations, like GET, are issued upon the request of the user
of the overlay. If a SIP UA issues a GET to discover peer's contact address,
the time for the lookup will be limited due to real time application's
characteristic which has tight demand for call-establishment time. 

So what I suggest here is to put the semi-recursive in the list of candidate
routing modes. 

BTW: If we have a requirement first, there may be no so many arguments here.
How about work out a requirement first and then go to the protocol design
work? 

Regards!
JiangXingFeng

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 26 Nov 2007 14:02:08 +0800

> to make such determinations.

IMHO, one viable method is to discover it during the enrollment procedure.
Up to now, community has agreed that some centralized servers, such as
enrollment server, bootstrap server are needed. These servers must be
supposed to be accessed by any nodes in the overlay. 

I think the meaning of the word "public" here is that STUN servers with
"public" addresses could be visited directly by any nodes in the overlay. If
the corresponding overlay will be operated globally, the STUN server or
other server must be equipped with a "real public address". If the overlay
is to be operated in a private scope, for example, in a private business
network, a node is thought of as having a public address even if it has a
address within private address range, for example, 10.; 

So I think it is up to the operator to determine where to deploy its STUN
servers or something like them to help nodes discovering its
service/capability easier.

Any comment is appreciated.

Regards!
JiangXingFeng

---

From: "David Barrett" <[email-masked]>
Date: Mon, 26 Nov 2007 02:01:30 -0800

> From: Eric Rescorla [mailto:[email-masked]]

For the record, there's a persistent myth that NAT classification is
difficult and unreliable.  It's not.  Just use several STUN servers that you
know are non-NAT'd, try various combinations, and you can classify
translation and filtering properties with a very high degree of reliability.
Granted, like everything with NATs (or, indeed, in the real world), it's not
perfect: sometimes you get false positives and negatives, and sometimes NAT
properties change over time.  But it's more than a reliable enough technique
to be useful.

-david

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Nov 2007 06:52:07 -0800

At Mon, 26 Nov 2007 02:01:30 -0800,
David Barrett wrote:
> difficult and unreliable.  It's not. 

Luckily, I didn't say any such thing.

> Just use several STUN servers that you
> know are non-NAT'd,

Yes, this is called assuming your premises. *Precisely* one of the
concerns here is the ability to collect a reliable set of STUN
servers.

Yes, you can probably get a good estimate, but because these semi-recursive
techniques don't do probing (a la ICE) but rather make the alleged
"public" node a bottleneck, a very high degree of reliability
is important.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Nov 2007 09:09:56 -0800

Sounds like a good suggestion to lay out some of the key requirements  
that will drive the designs... I'm sure there are many more but a few  
things I am thinking about below.

> How about work out a requirement first and then go to the protocol  

Works when many of the peers are behind NATs

Works with no centralized servers. One of the reasons I want this is  
so that things work if several perviously enrolled devices show up at  
an location of a emergency where some sort of adhoc network is up and  
running, and that adhoc network does not have connectivity to the  
global network. If we assume that we can use centralized servers,  
there are probably much easier solutions to this whole problem than  
most the current proposals in this WG.

Works while the DHT overlays are in the process of splitting, or  
joining due to the radical changes in the network connectivity.

Can resolve in under 5 seconds almost always and under 2 seconds most  
of the time. I realize these are very vaguely states and I would need  
to describe many other parameters to make them something we could  
design to but I can expand on this if it is useful. I find making  
them sort of "fluffy" helps not get wrapped around the axle on if a  
given design meets them or not.

Not preclude the system from being usable in a routing systems that  
allows peers to conceal key privacy related information while at the  
same time not requiring that every deployment have to do this.

Not exactly a requirements but a property that should be one of the  
properties that we try to optimize is ability to debug these  
networks. These tend to be some of the most complicated to diagnose  
systems I have ever worked with. The churn of peers make them  
significantly more complicated to diagnose that most distributed  
systems I have worked with and the inherent distributed system nature  
already made them much more complicated than a more traditional  
client/server architecture. Given the difficulty in diagnosing things  
on a typical SIP VoIP system today, I am very concerned about how  
hard it will be to diagnose things in these systems.

Cullen <with my individual contributor hat on>

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 26 Nov 2007 13:03:12 -0500

As folks who are actually already supporting shipping product on this
stuff, I wanted to strongly support Cullen's comment that we keep ease
of debugging in mind. We certainly have done so in our
product/proposals, and it requires a good bit of forethought to get
that right, but it is absolutely essential. Simplicity and the ability
to easily examine what is going on are key features...

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "David Barrett" <[email-masked]>
Date: Mon, 26 Nov 2007 12:11:48 -0800

> Luckily, I didn't say any such thing.

Ah, oops -- I misinterpreted your text.  I'm glad we agree NAT
classification is both possible and useful given a reliable set of STUN
servers.  Sorry for the confusion!

As for how to get the "reliable set of STUN servers" in the first place, I'm
assuming that when you contact the bootstrap service, it gives you a list of
STUN servers.  To start, the list would be populated by a "bootstrap STUN
service" (a small set of globally hosted STUN servers).  But as nodes are
added to the network, those who are not firewalled add themselves to the
list for future nodes to use.

The upshot is your pool of STUN servers scales with total network size.

Anyway, just piping up as I (mistakenly) thought I heard trash-talking about
NAT classification, and I wanted to chime in to set the record straight.

-david

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 26 Nov 2007 18:39:21 -0800

I strongly agree with both Cullen and David about the need for ease of
debugging P2PSIP systems.

The proof would consist in someone proposing tools for debugging P2PSIP
and actually reporting on their efficiency.

To make this actionable, how about adding this as a WG deliverable?
Even if it is a slightly longer term objective? 

Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Monday, November 26, 2007 12:03 PM
To: Cullen Jennings
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Requirements for Routing mode in P2PSIP

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Philip Matthews <[email-masked]>
Date: Tue, 27 Nov 2007 09:23:07 -0500

I would like to point out that are two related topics here:

1) Sending a message to a specific peer in the overlay, AND
2) Searching for a peer with a given property.

In the former case, you have a message (say a RELOAD OPEN message)  
that you wish to send to a specific peer, and you know the peer id of  
the destination. In the latter case, you are searching for a peer  
that, for example, holds a particular resource record; in this case,  
you don't know the peer id of the destination peer.

The idea that XingFeng is suggesting (of using a peer with a public  
IP address as a relay) was also suggested by Jani Hautakorpi in draft- 
hautakorpi-p2psip-with-hip-00. This idea applies to case (1), but is  
not appropriate for case (2).

I see this idea working as follows. Say a peer Z discovers, while  
setting up connections to other peers in the overlay, that its ICE  
host candidate H is the candidate selected in every case. This may or  
may not mean that H is a public IP address, but it does indicate that  
many other peers can reach Z using H. Thus Z, which has a user  
"Wilma", can insert the following resource record for Wilma into the  
overlay:
	contact:Wilma@Z; contact address:Wilma@H
This "Contact address" field specifies an address at which Z can  
likely be reached. This indicates that Z can likely be reached by  
sending a message directly to H.

Now say peer Z has a connection to peer Y, and the connection to peer  
Y uses a server-reflexive candidate for Y (in other words, Y is  
behind a NAT relative to Z). Then Z can say to Y: "I am willing to  
act as a relay for you". Thus Y, which has a user "Fred" can insert  
the following into the resource record for Fred:
     contact:Fred@Y; contact address:Fred@H
Here the contact address for Y is actually the address for Z, which  
will relay messages onwards to Y.

Peer X, upon retrieving a resource record with a contact address, and  
wanting to send a message, can do one of two things:
a) It sends the message to H, and waits for a short while. If no  
response is received, it sends the message hop-by-hop through the  
overlay.
b) It simultaneously sends the message directly to H, and hop-by-hop  
around the overlay.
Which one of (a) or (b) the peer X does can be a matter of local policy.

- Philip