Subject: [p2p-sip] What are we doing - question 1

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 01 Jun 2006 00:15:36 -0400

First of all, please let me clarify one thing - I never meant
interoperation between different DHTs.
I think it is/should out of scope.
What I assume is a DHT per a P2PSIP network. It seems all your questions
are based on the assumption that I was talking about interoperation of
different DHTs.
Interoperation between different P2PSIP networks? Please review my
slides of the ad-hoc meeting in Dallas. The interoperation is via RFC3261.

And I think we need to be specific about what interface (or protocol) we
are talking about when we talk about GET/PUT.

Thanks.

Eunsoo

Peter Pan wrote:

>The abstraction of GET/PUT seems ideal to wrap complex node interactions of
>different DHTs into a simple interface.
>
>Few questions:
>
>* Will there be some DHT "type tag" in the protocol so that a node in
>Kademlia DHT receiving a GET req from another node in Chord DHT will not
>dump irrelevant k closest nodes to the Chord node?
>* How will GET/PUT encapsulate difference of or convert distance "metric"
>information of different DHTs? (eg. Chord uses subtraction while Kademlia
>uses XOR to calculate node distance)
>* How will a node in DHT A locate the next-hop node in DHT B to send
>GET/PUT, which seems a precondition to interoperate DHTs on peer-to-peer
>basis?
>
>PP
>----- Original Message -----
>From: "Eunsoo Shim" <eunsoo at research.panasonic.com>
>To: "Cullen Jennings" <fluffy at cisco.com>
>Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
>Sent: Wednesday, May 31, 2006 9:07 AM
>Subject: Re: [p2p-sip] What are we doing - question 1
>
>
>  
>
>>Cullen Jennings wrote:
>>
>>    
>>
>>>On May 30, 2006, at 10:39 AM, Alan Johnston wrote:
>>>
>>>      
>>>
>>>>Cullen Jennings wrote:
>>>>
>>>>        
>>>>
>>>>>Ok, I'm glad to hear that at least some people think we have some
>>>>>consensus on this. It's been hard to tell following the list so I
>>>>>appreciate people speaking up about it.
>>>>>
>>>>>I'll be very blunt about doing both proposal. It is not clear to
>>>>>me  if people think we should do both because
>>>>>1) this is the technical long term solution we want, or
>>>>>2) this would make it so at some level everyone agreed.
>>>>>
>>>>>Doing both will no doubt slow down finishing either. It is not
>>>>>clear  to the that the GET/PUT only protocol would be used if the
>>>>>other GET/ PUT/JOIN/LEAVE exists - it seems like you would just
>>>>>want the later  of the two. So if we look at our end goal, is  there
>>>>>a need for GET/ PUT only.
>>>>>
>>>>>          
>>>>>
>>>>Yes.  Real DHT nodes typically interact with 100s if not 1000s of
>>>>peer nodes at any given instant.  Will every SIP UA be capable of
>>>>doing this?
>>>>        
>>>>
>>>I'll use chord as an example here not because I think chord is the
>>>right DHT but only as a concrete example. A node that knew a few
>>>other chord nodes but was not storing any data could easily interact
>>>with the DHT and only have very few connections.
>>>
>>>      
>>>
>>Please let me try to clarify the issure a little bit more.
>>
>>A node in Chord must maintain a finger table and data with keys of a
>>certain range or locations of such data.
>>Chord requires each node (in the Chord network) to have around log N
>>fingers (where N is the total number of nodes in the Chord network and
>>the base is 2).  So if the network size is around 64,000, the number of
>>fingers for each node is around 16. For a network of around a million
>>nodes, the number becomes around 20.
>>
>>There is a cost for maintaining the finger table when the network is
>>dynamic (nodes join and leave). Furthermore, each node should provide
>>routing for various Chord messages such as GET/PUT/JOIN/LEAVE.
>>
>>When a node has limited bandwidth or battery power, the above
>>requirements may be too much. If the node is behind NAT, it is not
>>simple maintaining connections with fingers and other nodes for which
>>the node is a finger.
>>
>>What I said kind of justifies the distinction between devices (SIP UAs)
>>that participate in the DHT (Chord) and devices (SIP UAs) that do not.
>>The devices that do not participate in the DHT don't need to support
>>JOIN and LEAVE but need to do just GET/PUT.
>>
>>So now we have two interfaces.
>>
>>Node in DHT                        Node in
>>DHT                              Node not in DHT
>>
>>
>>
>>    
>>
>|<---------------------------------------->|<-------------------------------
>----------------------->|
>  
>
>>             (a) GET/PUT                                      (b) GET/PUT
>>             JOIN/LEAVE
>>
>>Now the question has a few angles.
>>- Will (a) GET/PUT be dependent of the underling DHT algorithm?
>>- Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and
>>semantics?
>>- Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE?
>>
>>If an answer for any of the above question is 'yes', I think we'd be
>>better off by defining (b) GET/PUT as a separate protocol. And I think
>>it is a safe assumption.
>>If we find out none of the answers is 'yes', then we would not need a
>>separate protocol for (b) GET/PUT.
>>Nodes not in DHT can safely just implement and support GET/PUT but not
>>JOIN/LEAVE.
>>
>>Hope I added some clarity, not confusion.
>>
>>    
>>
>>>>Think wireless, low bandwidth, and embedded UAs.
>>>>There is a very clear layering and architectural choices here that
>>>>if we only somehow choose one single DHT and standardize it that we
>>>>will loose.
>>>>        
>>>>
>>>So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE
>>>protocol. This is the part that I am failing to understand. I think
>>>it would be great if we could have no central servers and not
>>>standardized a P2P protocol but I don't see how we can have our cake
>>>and eat it too.
>>>
>>>      
>>>
>>>>Also, I think we need to first decide what information should be
>>>>pushed and pulled from the DHT, what format it is, and how it will
>>>>be retrieved.  Then, and only then do we have the requirements for
>>>>our DHT layer.
>>>>        
>>>>
>>>I agree here but I don't see how this has to do with making a
>>>protocol for the GET/PUT.
>>>
>>>
>>>      
>>>
>>>>To do both of these efforts them at the same time makes no sense to
>>>>        
>>>>
>me.
>  
>
>>>Agree here too.
>>>
>>>      
>>>
>>Thanks.
>>
>>Eunsoo
>>
>>
>>    
>>
>
>
>  
>

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 01 Jun 2006 00:42:20 -0400

My comments are inline.

>>
>> One trivial comment and one important comment inline...
>>
>> On May 31, 2006, at 9:07 AM, Eunsoo Shim wrote:
>>
>  
>
>>>> Cullen Jennings wrote:
>>>>
>>    
>>
>>>>>>
>> the trivial comment - A trivial modification to the Chord algo would 
>> say that if a node wanted less finger tables, it dropped half the 
>> current ones and kept every other finger entry - things would still  work.
>  
>

Yes. Just at an expense of slower lookup.

>> I'm not arguing this is a good idea but I am pointing out there  are
>> many ways to modify a DHT to meet this somewhat requirement of  low
>> connection count.
>  
>

OK.

>> The problem with most low power devices is not  keeping up 20
>> connection but instead how often they have to wake up  for traffic. 
>  
>

Yes.

>> It may be that P2P is a real bad idea for mobile devices  because you
>> need to keep updating data. All this really does is worry  me that
>> selecting a DHT for use in mobile environments is a research  problem.
>  
>

It is possible to keep mobile devices as just ordinary
nodes (or clients) that do not participate in DHT routing if a P2PSIP
network includes fixed devices and mobile devices.

A P2PSIP network with only mobile devices? Well, if Mobile IP is
supported for the devices, there is nothing to worry. DHT won't be
affected by their mobility. No Mobile IP? Well, then it is a very
dynamic DHT. I am not sure whether we should worry about such a case at
the moment.

>> True that it is not easy but it's not clear that it is any harder 
>> than setting up RTP between two devices behind NAT which I believe to 
>> be a requirement of this work.
>  
>

For a given pair of nodes, I guess it is the same task as setting up a
RTP channel.
The difference is that, if a node behind NAT participates in DHT, it
should maintain multiple or many of such channels with nodes which may
change over time.
For Chord, a JOIN operation involves of O(log2 N) messages when no NAT
is involved. If NATs are involved, I am sure more traffic will be
required for a JOIN operation.

>>>> |<---------------------------------------->|
>>>> <------------------------------------------------------>|
>>>>              (a) GET/PUT                                      (b) 
>>>> GET/PUT
>>>>              JOIN/LEAVE
>>>>
>> Yes sort of. I think what you are saying is that if any of the 
>> answers are yes, then we will not be able to build an interoperable 
>> protocol to do the (a) side so we will need the (b) protocol. Do I 
>> have this right?
>>
>  
>
I am afraid that my message was not clear enough.
No matter what the answers of the three questions are, we can build an interoperable protocol
to do the (a) side. And I believe we should build one.
The question I tried to answer was when/why we would need to build a
separate protocol to do the (b) side in addition to the protocol for the
(a) side.
My answer to the question is that it is a safe assumption that we would
be better off if we plan to design a separate protocol to do the (b) side.
So I am proposing that we put the two protocols in the charter as
deliverables.

Thanks.

Eunsoo

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 01 Jun 2006 10:29:18 +0200

> So I am proposing that we put the two protocols in the charter as

The IETF has a liason with 3GPP which has specified a GET/PUT protocol
as an extension for the DIAMETER protocol.  Moreover, the DIME WG in the
OPS Area has a charter which starts:

  The Diameter Maintanence and Extensions WG will focus on maintenance
  and extensions to the Diameter protocol required to enable its use
  in applications such as IP telephony and Local Area Network
  authentication, authorization and accounting.

I don't know the liason in details and perhaps we could argue that
retrieving and storing is not AAA, but I'm pretty sure that If we put
the GET/PUT only protocol in the charter, we will get a "go with DIME"
from IAB and IESG members.  Cullen, please correct me if I'm wrong ;-)

Sorry for being repetitive.

Enrico

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Thu, 1 Jun 2006 10:28:32 -0400

Peter:

You raised very pertinent questions.

The people that are proposing the interworking between DHTs  seem to be 
ignoring the
fact how difficult interworking of two different DHT name spaces is.

Since each implementation of DHT is so different, and manages name spaces 
very differently,
it will require major research to map DHT name spaces and I haven't so far 
seen any research
work in this direction. Just to believe that creating API level semantics of 
get and put can mask
such major technical difficulties, imho,  is trivializing the problem.

In any case, IETF has always left definition of any APIs to implementers 
whether terms are
Get or Put, or  Deposit and Retrieve, hence assigning meaning to such terms 
is a bad practice.

cheers,

--bk

----- Original Message ----- 
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "Eunsoo Shim" <eunsoo at research.panasonic.com>; "Cullen Jennings" 
<fluffy at cisco.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Wednesday, May 31, 2006 8:13 PM
Subject: Re: [p2p-sip] What are we doing - question 1

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Thu, 1 Jun 2006 10:48:36 -0400

Cullen wrote:

>The problem with most low power devices is not
> keeping up 20 connection but instead how often they have to wake up
> for traffic. It may be that P2P is a real bad idea for mobile devices
> because you need to keep updating data. All this really does is worry
> me that selecting a DHT for use in mobile environments is a research
> problem.

Very good observation that seemed to be missing from the perspective so far.

Without sleep mode in OTA protocols,  battery life will go down to hours
(just about equal to talk time on a typical mobile handset). But, a mobile 
node can
be a greedy node - join, use service and get out from the network - a lot of 
churn
might cause some DHT instability and more traffic to other nodes (if they 
are mobile
some loss of battery again). But, it might still  work....  (well, same 
issues that have
deterred widespread uses of  mobile video broadcast in handsets so far!!).

cheers,

--bk

----- Original Message ----- 
From: "Cullen Jennings" <fluffy at cisco.com>
To: "Eunsoo Shim" <eunsoo at research.panasonic.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Wednesday, May 31, 2006 10:33 PM
Subject: Re: [p2p-sip] What are we doing - question 1

> current ones and kept every other finger entry - things would still
> work. I'm not arguing this is a good idea but I am pointing out there
> are many ways to modify a DHT to meet this somewhat requirement of
> low connection count. The problem with most low power devices is not
> keeping up 20 connection but instead how often they have to wake up
> for traffic. It may be that P2P is a real bad idea for mobile devices
> because you need to keep updating data. All this really does is worry
> me that selecting a DHT for use in mobile environments is a research
> problem.
>
>>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 1 Jun 2006 08:19:22 -0700

It reads like that anyone who will or have been working on building p2p sip
networks can no longer wait for any P2P SIP protocol possibly standardized
here, and can now go ahead start building theirs by any "internal" p2p
protocol over any DHT. As long as they can interoperate with others (P2P SIP
standard followers or not) via RFC 3261 gateways (or their UA is SIP based),
none will lose.

Not bad.

PP
----- Original Message -----
From: "Brijesh Kumar" <bk9001 at gmail.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>; "Cullen Jennings"
<fluffy at cisco.com>
Cc: "P2P-SIP" <p2p-sip at cs.columbia.edu>
Sent: Thursday, June 01, 2006 7:28 AM
Subject: Re: [p2p-sip] What are we doing - question 1

GET/PUT

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sat, 3 Jun 2006 15:21:00 -0700

> from IAB and IESG members.  Cullen, please correct me if I'm wrong ;-)

Oh, I have no idea what you would get from IAB or IESG. I doubt the  
conversation is well enough formed or enough information is on the  
table for the IESG or IAB to really form an opinion on the topic.

However, from me as individual contributor, you do have the  
outstanding question of why a SIP REGISTER is not sufficient to do  
the GET and PUT. The advantage of this is that existing UA devices  
could already be talking protocol (b). There has been suggestion that  
this might not be clear for finding a services such as a TURN server  
but I did make a proposal for that based on some sort of service URI  
like convention.

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Sun, 04 Jun 2006 18:04:58 +0200

Cullen Jennings wrote:
> However, from me as individual contributor, you do have the outstanding
> question of why a SIP REGISTER is not sufficient to do the GET and PUT.
> The advantage of this is that existing UA devices could already be
> talking protocol (b). There has been suggestion that this might not be
> clear for finding a services such as a TURN server but I did make a
> proposal for that based on some sort of service URI like convention.

That's exactly the solution David and me have proposed for connecting
P2P SIP overlays and traditional SIP domains in
draft-marocco-sipping-p2p-scenarios.  We would really appreciate
comments about it; so far we haven't received any.

Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 16 Jun 2006 11:37:41 -0400

> required for a JOIN operation.

Which is why I don't think _vanilla_ Chord is a very good solution  
for P2PSIP.
IF we choose Chord, then P2PSIP allows us to make some fairly simple  
modifications
that reduce the overhead of joins and leaves.
For example, we might require peers to re-register every 15 seconds,
in which case the P2PSIP network might not have to do any work when
a peer leaves.
(Note that the SIP proxies for a major VoIP provider today currently  
enforce
a 15 second timeout for registrations, so this is clearly workable).

- Philip

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 16 Jun 2006 11:42:31 -0400

Fully agree. At least from my experience both on the research side and
my commercial implementation work, we had to tweak whatever algortithm
we selected. My thought is we start with some DHT as a starting point
and work on making it "optimized" for VoIP systems.

David Bryan

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 16 Jun 2006 18:17:29 +0200

> a 15 second timeout for registrations, so this is clearly workable).

That's right.  A short interval between successive stabilizations would
also permit to maintain a fairly good finger table based only on the
info retrieved from a few peers.  This is IMHO the most important
optimization, because querying hundreds of peer as _vanilla_ chord
requires would be prohibitive in most of the environments where P2PSIP
could be useful.

Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 16 Jun 2006 11:37:05 -0400

[A belated comment on this -- sorry, but I  have been busy with  
another project recently]

I completely agree with Cullen's comments on this. To re-iterate with  
a few extra comments
of my own:

1)  IF we use a method like Chord as the distributed lookup mechanism
      (and I happen to think that there are other, non-DHT  
approaches, which
      have some attractive properties that Chord and other DHTs do not),
      then if a peer cannot keep the full finger table (because it is  
a wireless node
      or because it is behind a NAT), then it  can drop every other  
finger table entry
      and everything  still works, albeit with reduced performance.

2) Maintaining connections behind NATs does require a bit of work  
when the
     connection runs over UDP, especially if the peer is also wireless.
     However, it is easier when the connection runs
     over TCP.  If our finger table connections run over TCP, then  
the effort of
     maintaining 20 of them may be equal to the effort required to  
maintain
     a single voice connection over UDP.

- Philip

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 16 Jun 2006 18:49:37 +0200

>      a single voice connection over UDP.

The problem for a node behind a NAT is not maintaining connection with
its fingers; instead, what is really difficult is being reachable from
any peer.  Unfortunately chord requires the latter.

Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 16 Jun 2006 13:37:26 -0400

[Removing Cullen from the CC list as he is probably pretty swamped  
right now ...]

> any peer.  Unfortunately chord requires the latter.

Not true. If peers forward requests on to other peer, a individual  
peer only
has to have connections to a very small subset of the entire peer  
population.

In other words, say peer A wants to reach peer Z. Say A does not have  
a direct
connection to Z, but does have a direct connection to (say)  B and C.  
It picks
the one that is closest to Z (say C), and forwards its message (say a  
SIP INVITE)
to C. Peer C then looks at its finger table and discovers that it,  
too, does not have
a direct connection to Z, but has a connection to D which is closer.  
So C forwards
the message to D. And so on.

Eric Cooper and I talked  about this in the Internet Draft that I  
presented
  at the last P2PSIP ad-hoc in Dallas:
    http://www.p2psip.org/drafts/draft-matthews-p2psip-nats-and- 
overlays-00.html
See section 4.4.2.  Note that another problem with vanilla_Chord  
identified in
this document is that it does not exhibit the "Symmetric Interest"  
property
(see section 4.4.3). However, a fairly straight-forward modification  
does.

- Philip

---

From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 16 Jun 2006 11:27:59 -0700

>       have some attractive properties that Chord and other 

I agree. Somewhere between "non-DHT" and "DHT-like" is probably the right
answer for this problem.

>       then if a peer cannot keep the full finger table 
> (because it is a wireless node
>       or because it is behind a NAT), then it  can drop every 
> other finger table entry

True for recursively-routed DHTs, not true for iteratively-routed DHTs.

Matthew Kaufman
matthew at matthew.at
http://www.amicima.com

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 16 Jun 2006 21:04:46 +0200

Philip Matthews wrote:
> Not true. If peers forward requests on to other peer, a individual peer
> only
> In other words, say peer A wants to reach peer Z. Say A does not have a
> direct
> connection to Z, but does have a direct connection to (say)  B and C. It
> picks
> to C. Peer C then looks at its finger table and discovers that it, too,
> does not have
> a direct connection to Z, but has a connection to D which is closer. So
> C forwards

True.  However this does not hold for an iterative implementation of chord.

> Eric Cooper and I talked  about this in the Internet Draft that I presented
>    http://www.p2psip.org/drafts/draft-matthews-p2psip-nats-and-overlays-00.html
> See section 4.4.2.  Note that another problem with vanilla_Chord identified in
> this document is that it does not exhibit the "Symmetric Interest" property
> (see section 4.4.3). However, a fairly straight-forward modification does.

Without such a property, the number of connections each node needs for
keeping the complexity logarithmic is huge: at least logN (where N is
the number of nodes in the overlay, not the cardinality of the hash
function) from it toward its fingers and - I guess, but I'm not sure -
logN originated from nodes in the DHT which have it as a finger.  Do
these numbers agree with your analysis?

Enrico

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 16 Jun 2006 17:31:59 -0400

> I agree. Somewhere between "non-DHT" and "DHT-like" is probably the  

Yes. My main concern with DHTs are that they cannot do wildcard searches
efficiently. You have to know my exact AOR to phone me.

Unless I can always be, for example, "philip_matthews" in every   
P2PSIP network,
it will be hard for you to figure out how to phone me without an e- 
mail exchange
or similar if you must enter my exact AOR.

But if I can search for "Philip Matthews" and get back a list of  
users with some
extra identifying information, you have a good chance of finding and  
phoning me.

- Philip

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 16 Jun 2006 18:33:01 -0400

Hmmm...interesting, but registrar functionality isn't really about
search. If we are just building a replacement for registration that is
distributed, search isn't a fundamental feature.

David

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 16 Jun 2006 15:45:33 -0700

In worse case, AOR search can be achieved by flooding. Who will feel and
mind it?

---

From: arjunrc at gmail.com (Arjun Roychowdhury)
Date: Fri, 16 Jun 2006 20:17:58 -0400

Has anyone looked at hybrid architectures such as p-grid
(www.p-grid.org). The p-grid network is structured as a combination of
DHT functionality and a tree topology. Keys can then be stored as a
function of the node-id value, instead of it being random, and a
binary search could be done on node-id prefixes emulating a wildcard
search.

regds
arjun

-- 
Arjun Roychowdhury

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 16 Jun 2006 20:32:36 -0700

> the message to D. And so on.

Will response traverse the same forwarding path (Z=>D=>C=>A)?

If yes, this heuristic can leave uncertain number of outstanding call legs
(and possibly loops) along the path.

If no, Z's response sometime cannot penetrate A's NAT.

Is it more decisive for A to first GET Z's location(s) and then shot the
request directly to Z?

Thanks.

Peter

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Sun, 18 Jun 2006 13:48:48 -0700

It's clear that the NAT issues do change how you might desire the DHT  
(or something similar) to deal with routing. If you pick something  
without considering NAT, I suspect it will be very hard to move it to  
NAT later. Because of this, I felt we wanted to have the NAT  
requirement in scope in the charter. It's clear that something like a  
iterative routed chord could probably work with NATs but not clear  
that is the best. Iterative routing has more problems from a security  
point of view than recursive routing because it is easier to reroute  
large parts of they namespace. I don't think we need to   choose a  
solution to get to the point we have a charter but I do think this is  
part of the problem I want to deal with.

Cullen <with my individual hat on>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 18 Jun 2006 20:44:34 -0400

Hmmm...I think you might have iterative and recursive mixed up here,
unless I'm missing something. Recursive (think proxy server) would be
good for NAT punching, since you only need to keep connections to your
fingers and nothing else. Iterative (think redirect server) on the
other hand will require arbitrary punching.

In addition to the point you made, on the security side, although the
recursive mechanisms may gain you in firewall traversal, they can also
be a DoS magnifier (or at least obfuscator) since you can send
requests to nodes that then proxy that request on on behalf of the
sender. Definitely an issue to weigh the security implications vs. the
NAT traversal ease. (we've actually done a tech report at W&M that
addresses the tradeoffs of recursive vs. iterative as one section, it
is available here:
http://www.cs.wm.edu/~lowekamp/papers/wm-cs-2006-03.pdf)

--David

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 19 Jun 2006 17:01:34 -0400

> Is it more decisive for A to first GET Z's location(s) and then  

We envision that the  request and the response would be routed  
separately
through the network. So the response might go Z => R => Q => A.
This would be because C => A might be a short hop, but in the return  
path,
Z tries to cover as much of the distance back to A on the first hop  
as it can,
hence the Z => R hop.

[All this would probably be much more understandable if we were standing
in front of a whiteboard ...]

- Philip

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 19 Jun 2006 17:28:17 -0700

Good point - I guese what I really should say is it is clear there  
are interactions between the NAT traversal properties and security  
properties of any given method and I'm not clear what the interaction  
and trade offs are. I would suspect that we might want to scope this  
into the work that a WG was going to look at.

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 20 Jun 2006 10:11:09 -0400

Fully agree. This particular issue proves the broader point -- we
*must* address security and NAT traversal from day one or it simply
won't work. If there is a WG formed here, ensuring both are included
(while allowing for systems such as ad-hoc that don't need as strong
of a level of these features to not be unduely burdened) should be a
must.

David

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 20 Jun 2006 11:55:50 -0400

I also fully support looking at security and NAT traversal issues  
from day one.
Neither of these are things that  can easily be added later.
- Philip

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 26 Jun 2006 10:04:34 -0700

> In worse case, AOR search can be achieved by flooding. Who will  

Peter, I don't understand your question - if it already got answered  
or was not a question, then there is no need to reply. If there was a  
key question that needed to be answered here, try and explain a bit  
more because I did not understand.

Thanks, Cullen

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 26 Jun 2006 13:07:51 -0700

> more because I did not understand.

Thanks for the asking. "AOR search" is typo; it should be "name search".

Skype might use flooding search as well. You can see a green neon running
above for quite some time after you initiate a name search, in the meanwhile
discrete replies in udp packets arrive continuously for several seconds.
(Search results from central servers usually come in batches and all in
once) Unless you use sniffer to see the flooding, you can hardly feel it.

Peter

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 26 Jun 2006 17:04:10 -0400

Hi Peter,

> once) Unless you use sniffer to see the flooding, you can hardly feel it.

I actually think that searches of any sort are out-of-scope.
Perhaps there would be guidance available on such mechanisms
from IRTF, but the scope of the WG should be drilled down tight,
so we can make progress.

It's an important application, but not one which needs to be
available for P2P-SIP on day one.

Greg.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 26 Jun 2006 14:24:36 -0700

Hi, Greg.

Totally agreed. This is why I mention-ed the bottom line, flooding search,
after someone earlier in the thread seemed worrying about name search in
DHT.

Peter
----- Original Message -----
From: "Greg Daley" <gregd at research.panasonic.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Cullen Jennings" <fluffy at cisco.com>; "P2P-SIP"
<p2p-sip at cs.columbia.edu>; "David A. Bryan" <bryan at ethernot.org>
Sent: Monday, June 26, 2006 2:04 PM
Subject: Re: [p2p-sip] What are we doing - question 1