Subject: [p2p-sip] P2PSIP, Kademlia and caching

From: sayer at cs.tu-berlin.de (Stefan Sayer)
Date: Wed, 24 May 2006 02:01:36 +0200

Hello p2psippers,

does Kademlia's caching scheme disqualify it from being used as DHT 
for P2PSIP?

I see two problems with it:
  - stale values of the user's location could persist, as the update 
performed by the client will probably not reach all the cached copies
  - is it possible to require authentication for a stored record? in 
the caching scheme in the original kademlia paper it says "For caching 
purposes, once a lookup succeeds, the requesting node stores the 
(key,value) pair at the closest node it observed to the key that did 
not return the value.", and the requesting node does not have the 
credentials.

Especially the second one troubles me, any mechanism to prevent 
identity theft needs authentication. For example, 
draft-shim-sipping-p2p-arch-00 Section 9. for the add function 
mentiones that a security credential will be associated with the 
record, if its updatable, and it seems to me that this clearly 
disqualifies Kademlia.

Or is it that just the caching would not be used and only the original 
publisher be allowed to update or remove an entry?

Regards
Stefan Sayer

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 24 May 2006 07:56:32 -0500

>From a practical point of view, it seems Bamboo (http://bamboo-dht.org/ )
used in Open DHT (http://www.opendht.org/ ) is the most obvious option at
this point in time. A lot of experience and work went into Bamboo; it is
quite mature apparently. 

More research will probably reveal even more refined application level
routing protocols, but Bamboo seems OK for now.

Do any p2psippers have an opinion on this?

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Stefan Sayer
Sent: Tuesday, May 23, 2006 7:02 PM
To: p2p-sip at cs.columbia.edu
Subject: [p2p-sip] P2PSIP, Kademlia and caching

Hello p2psippers,

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 24 May 2006 11:37:55 -0400

I think Bamboo is a good starting point.
Still we might want to define our requirements for the DHT algorithm(s)
for P2PSIP.
Thanks.

Eunsoo

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Wed, 24 May 2006 12:08:44 -0400

I think there are a lot of good points about Kademlia, but I'm not
sure that the caching component is a good idea for p2psip.  (this will
be easier to answer, of course, with a more formal requirements
analysis.)   Kademlia's caching is designed for systems where there is
a lot of search locality---some items are much more popular than
others.  I don't think we have the same type of locality in any/most
p2psip environment(s), so I don't think the caching buys us any
performance increase.  As you point out, it actually increases the
likelihood of retrieving a stale registration (presumably cached
values would time out quickly, but there's still that chance).

I don't think caching adds any complexities for authentication---if
you're working in an open P2P system you're probably assuming you have
an untrusted network to begin with and will be trying to validate any
registration, regardless of whether it's cached or not.

Bruce

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 24 May 2006 12:23:23 -0400

I think Bamboo is certainly one to consider, but I think others are
strong contenders too. Kademlia is certainly one that has a number of
things going for it. It is used in eDonkey, so I think it is as well
established (maybe more so) than Bamboo. (Not that there is anything
wrong with Bamboo, either).

I think we should also consider implementation ease when choosing one.
Has anyone here implemented both? Any thoughts?

David

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 24 May 2006 14:54:47 -0500

> Any thoughts?

Maybe a list of criteria for selection would make sense: An I-D with
selection criteria and/or requirements.

My two cents, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Wednesday, May 24, 2006 11:23 AM
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu; henry at pulver.com
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

David

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Wed, 24 May 2006 15:17:42 -0700 (PDT)

With all these mails on DHTs, it is obvious that there cannot be an agreement on what DHT to use for any p2p protocol. As for in-house stuff one is free to use any DHT algorithm, but to standardize a protocol on a particular DHT by pushing through IETF process will be a grave mistake, unless someone tells me that the final word on DHT has been spoken. 

I would rather see many approaches developed and code put on sourceforge.net from people that are asking to standardize so that interested persons can run the code and compare before any standardization discussion gets done in this direction in  any forum.  Once we have comparable code, it will be easy to form opinions on various DHTs. The people that are pushing white papers from their company labs should instead submit actual code, if they so believe in the merit of their design proposal if any. 

- Mike

Henry Sinnreich <henry at pulver.com> wrote: > Any thoughts?

My two cents, Henry

-----Original Message-----

David

		
---------------------------------
Be a chatter box. Enjoy free PC-to-PC calls  with Yahoo! Messenger with Voice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060524/6a2ad851/attachment-0001.html

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 24 May 2006 19:10:00 -0400

Hi Mike,

Mike Robinson wrote:
> 
> With all these mails on DHTs, it is obvious that there cannot be an 
> agreement on what DHT to use for any p2p protocol. As for in-house stuff 
> one is free to use any DHT algorithm, but to standardize a protocol on a 
> particular DHT by pushing through IETF process will be a grave mistake, 
> unless someone tells me that the final word on DHT has been spoken.
> 
> I would rather see many approaches developed and code put on 
> sourceforge.net from people that are asking to standardize so that 
> interested persons can run the code and compare before any 
> standardization discussion gets done in this direction in  any forum.  
> Once we have comparable code, it will be easy to form opinions on 
> various DHTs. The people that are pushing white papers from their 
> company labs should instead submit actual code, if they so believe in 
> the merit of their design proposal if any.
> 

Henry's idea of requirements and assessment criteria is a really
good one though, which necessarily predates that.

Unless we know what we're designing for, it doesn't make sense
to go ahead and cite (or implement) protocols.  I'd much prefer
to be comparing apples to apples.

Greg

---

From: br at brianrosen.net (Brian Rosen)
Date: Wed, 24 May 2006 19:21:19 -0400

But then the question is:

Can we, at this point in time, create a meaningful requirement/assessment
document?

One way to figure that out is to just propose a requirement, right here on
the list.  If we get a bunch, and we see some consensus on direction,
perhaps we could make progress.

That would be nice.

Anyone got a requirement to share?

Brian

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Greg Daley
Sent: Wednesday, May 24, 2006 7:10 PM
To: Mike Robinson
Cc: p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A. Bryan'
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

Hi Mike,

Greg

---

From: sayer at cs.tu-berlin.de (Stefan Sayer)
Date: Thu, 25 May 2006 02:16:55 +0200

Hello,
> registration, regardless of whether it's cached or not.
'validate' means for me in this context that the one who wants to 
register really is the one that has on sign-up reserved that name.

What I don't understand: If every node is admitted to publish or 
update a record (which is true for a system that does caching), for 
example my location record, how can identity theft be prevented?

* if every node is admitted to change a value associated to a key then 
anyone can steal the identity very easily

* if every node is admitted to republish a <key,value> pair (be it at 
cache places or some original root of the key), regardless of whether 
it is the original publisher of the pair, then an attacker could still 
litter the overlay with corrupted values

So I would see the requirement as follows:
   The overlay MUST support binding a credential to a key, in order to
   authenticate the original publisher of a <key,value> pair in update
   and remove operations.

On the API level, for example starting from the definition in 
draft-shim-sipping-p2p-arch-00 Section 9, I would add the credentials 
directly as parameter to the functions add, update, and remove:
get(in overlay_id, in key, out records, out error)
add(in overlay_id, in key, in record, in lifetime, in option,
     in credential, out error)
update(in overlay_id, in key, in record, in lifetime, in option,
        in credential, out error)
remove(in overlay_id, in key, in credential, out error)

As much as I like Kademlia, as I understand it at the moment without 
modifications it does not support this. But I might very well have 
overlooked something.

Regards
Stefan

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 07:28:26 -0400

Hi Brian,

I do think that we are ready to start gathering the requirements
and some people are working on that now.

What we have to remember is that the main goal at the moment
is to get a working group chartered, rather than a DHT chosen
though (let's see if we can be productive and get some firm
requirements without adding confusion to the charter discussion).

Discussion on list seems a good way to start gathering requirements,
but there are others which will turn up through systematic appraisal
too.

Greg

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 07:33:18 -0400

Hi Stefan,

Short comment at the bottom.

> modifications it does not support this. But I might very well have 

Thanks for your analysis.  You're right in that without security
built into the DHT, it is potentially possible to overwrite, or
swamp a particular record (dependent on the particular DHT's semantics).

This a good example why we cannot use an existing system without
thorough requirements analysis.

Greg

---

From: niedermayer at informatik.uni-tuebingen.de (Heiko Niedermayer)
Date: Thu, 25 May 2006 14:14:02 +0200

Hello,

commenting on all the mails on DHts. Well, I assume that the choice of 
DHT is of minor importance and that any DHT will at least do after 
adapting it to P2PSIP. But, why not build a specialized p2p network for 
P2PSIP. SIP is not a pure hash table service, so why transform a SIP 
network to a hash table?
However, the big problem I see is that there is no convincing solution 
to provide security. Say, if I want to communicate with Nokia I might 
end up at Ericsson, that is fatal. And moreover, I do not want my 
personal data and behaviour be manged and tracked by peers I can and do 
not trust.

So, the general question is if there is a way to secure P2PSIP and to 
provide privacy. In an open environment this is probably not possible. A 
closed P2PSIP network is no real value-add from my point-of-view. With 
respect to credentials, I assume that credentials are fine if the 
network is a closed infrastructure network and clients are not part of 
the network.

Regards
 Heiko

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 25 May 2006 08:53:47 -0400

>From what I can gather, one of the big sticky issues associated with a
charter is whether there is sufficient grounds to achieve consensus.
If the big picture on requirements was established, that is prima fascia
evidence that there is some consensus on how to go forward.

So, I think requirements discussions, now, before there is a charter, is a
good idea.  Seems like you agree, so let's have some on the table.  If there
are groups working on some, get a draft published, and let's look at them.

Let's start with DHTs:
1. Do we have consensus that P2PSIP, as would be defined by this group, is
DHT based?
2. Is there a requirement for support of multiple DHTs?  What would be the
requirements a DHT needed to have in order to be acceptable?

Brian

-----Original Message-----
From: Greg Daley [mailto:gregd at research.panasonic.com] 
Sent: Thursday, May 25, 2006 7:28 AM
To: Brian Rosen
Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu; henry at pulver.com; 'David A.
Bryan'

Hi Brian,

Greg

---

From: henry at pulver.com (Henry Sinnreich)
Date: Thu, 25 May 2006 10:17:45 -0500

>What we have to remember is that the main goal at the moment is to get a
>working group chartered

Yes, and can everybody on the list please remember this one and only one
goal at this point in time?

Thanks, Henry

-----Original Message-----
Sent: Thursday, May 25, 2006 6:28 AM

Hi Brian,

Greg

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 25 May 2006 11:37:53 -0400

I concur with that.  Focus focus focus.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/646c8a15/attachment.html

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Thu, 25 May 2006 11:43:20 -0400

I think one of the lessons from working on the use-cases draft is that
there are a wide range of scenarios with differing levels of trust and
authorities that make good scenarios for p2psip.  What exactly we'll
attempt to standardize will come out of the WG charter and
requirements drafts.

Personally, I'm a big fan of having a protocol that supports several
identity authentication options, since I don't think there will be a
single one-size-fits-all solution for the different use-cases.  The
scenario you propose is easily solvable if you allow for the existence
of loosely-connected CAs and use the DHT to store certificates.  I
think there are ideas for how to do it in a more distributed manner,
but I don't know that they are at the level of something we could
write a standard for, whereas certificate chains are well-understood.

There are other variations, though---if you don't have CAs, then
everyone can generate and publish their own public keys.  I couldn't
prevent someone else from claiming to be lowekamp at cs.wm.edu, but they
couldn't fake signing my messages with my key (they could confuse the
situation because there would be multiple lowekamp at cs.wm.edu
identities with different keys).    What you have then is basically
the same as the current pgp keyserver system, which works as long as
you have some way of verifying the key when you first acquire it.

Bruce

---

From: henry at pulver.com (Henry Sinnreich)
Date: Thu, 25 May 2006 10:55:00 -0500

> have some way of verifying the key when you first acquire it.

Yes, this is exactly what ZRTP and the Zfone are doing.

http://www.philzimmermann.com/EN/zfone/index.html 

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp
Sent: Thursday, May 25, 2006 10:43 AM
To: Stefan Sayer
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

Bruce

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Thu, 25 May 2006 12:04:02 -0400

Henry,

I haven't looked at ZRTP much, but doesn't he explicitly say he
doesn't do this in the last FAQ at
http://www.philzimmermann.com/EN/zfone/index-faq.html
?

I'm not entirely sure I agree with this argument, BTW.  I mean, he's
right about the current PSTN security model, but I really think that a
system that supports instant messaging needs a bit
more---impersonation is much easier there.

Bruce

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Thu, 25 May 2006 11:23:09 -0700 (PDT)

Greg:

I am a little confused as to what is you are suggesting.

On one hand, you are accepting  that you need time to understand differences of DHT algorithms behavior and we need time to study that, on the other you and your colleagues are saying there is need to chart an IETF group for design of p2p sip and push a pre-mature design through in a hurry.  Both can't be true since they are contradictory in nature.

P2p DHTs in general belong to the  IRTF p2p group which already exists. Any comparative work on DHTs belongs there, and unless that group reaches some meaningful conclusions, proposing a p2p sip design, based on a particular versions of DHT, is simply harmful to the interests of every one except those who have vested interest to speedup adoption of their view of the world. 

No one is even sure if sip is the right protocol for DHT management except that someone thought so, or found it easier to code for whatever reason. 

My 2 cents.

o Mike

Greg Daley <gregd at research.panasonic.com> wrote: 
Hi Mike,

Greg

---------------------------------
How low will we go? Check out Yahoo! Messenger?s low  PC-to-Phone call rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/de446445/attachment-0001.html

---

From: mike_robnson at yahoo.com (Mike Robinson)
Date: Thu, 25 May 2006 11:42:19 -0700 (PDT)

Henry Sinnreich <henry at pulver.com> wrote: >What we have to remember is that the main goal at the moment is to get a

And by the way,  whose "goal" are we talking here?

Unless someone can tell us clearly why sip should be used to create, manage and re-configure DHT, the goal should remain a "proposed goal" till then. IETF, or for that matter any standard organization should't be a willing tool to fulfil any particular company's vested interests (even when supposedly supported by  (a company  funded) researchers at a University).

I am not opposed to p2p sip in whatever form - but don't understand the urgency being shown to push a certain design without evaluating alternative approaches. You don't  need standardization right away to show that your model works- post your code to sourceforge.net and let me see how good your design is by experimenting with it.

o Mike 

Henry Sinnreich <henry at pulver.com> wrote: >What we have to remember is that the main goal at the moment is to get a

Thanks, Henry

-----Original Message-----

Hi Brian,

Greg

		
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/795568c6/attachment.html

---

From: alan at sipstation.com (Alan Johnston)
Date: Thu, 25 May 2006 13:54:39 -0500

Bruce,

I think Henry's point was that ZRTP provides confidentiality and 
authentication services without certificates or a PKI. 

In simple terms, it uses key continuity similar to (but not the same as) 
SSH across subsequent media sessions between two endpoints.

This type of architecture could be a useful for P2P SIP.

Thanks,
Alan

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Thu, 25 May 2006 15:34:10 -0400

It does exactly that.  It replaces certs with humans, which are more
trustworthy.

If P2P can also mean H2H (Human to Human) there is nothing stopping this
approach from being valid.

We have to step back sometimes and remember that humans are part of the
equation,  we underestimate ourselves.

M

-- 
Michael Slavitch
Ottawa, Ontario Canada

"Yet another P2PSIP Henchman"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060525/62e78ea3/attachment-0001.html

---

From: henry at pulver.com (Henry Sinnreich)
Date: Thu, 25 May 2006 14:37:23 -0500

Mike,

There seems to be some confusion here:

>Unless someone can tell us clearly why sip should be used to create, manage
>and re-configure DHT,

This was not meant at all. Actually, several recent I-Ds propose SIP to use
an external or separate DHT instead of the location database and/or DNS as
are used by SIP proxies in the CS model.

Please see: 
http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-02.txt
The authors would appreciate comments on this I-D :-)

The _Location Service Protocol_ is proposed there to link SIP to an
unspecified DHT. 

Actually, using the openDHT would be a practical start IMHO:
http://opendht.org/

Thanks, Henry

________________________________________
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Mike Robinson
Sent: Thursday, May 25, 2006 1:42 PM
To: henry at pulver.com; 'Greg Daley'; 'Brian Rosen'
Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan'
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

Henry Sinnreich <henry at pulver.com> wrote: >What we have to remember is that
the main goal at the moment is to get a

And by the way,? whose "goal" are we talking here?

Unless someone can tell us clearly why sip should be used to create, manage
and re-configure DHT, the goal should remain a "proposed goal" till then.
IETF, or for that matter any standard organization should't be a willing
tool to fulfil any particular company's vested interests (even when
supposedly supported by? (a company? funded) researchers at a University).

I am not opposed to p2p sip in whatever form - but don't understand the
urgency being shown to push a certain design without evaluating alternative
approaches. You don't? need standardization right away to show that your
model works- post your code to sourceforge.net and let me see how good your
design is by experimenting with it.

o Mike 

Thanks, Henry

-----Original Message-----

Hi Brian,

Greg

________________________________________
New Yahoo! Messenger with Voice. Call regular phones from your PC and save
big.

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Thu, 25 May 2006 15:41:34 -0400

----- Original Message ----- 
From: "Heiko Niedermayer" <niedermayer at informatik.uni-tuebingen.de>

> P2PSIP. SIP is not a pure hash table service, so why transform a SIP

Good question that is very hard to answer except to say that this is the 
easiest
thing  to do, and code. Well, hopefully someone will comeout with more
cogent answer.

> personal data and behaviour be manged and tracked by peers I can and do

As you know, p2p application security without a confederated security
framework is not possible. You need to trust someone to be able to get in - 
the
question is who will issue credentials, for a large network, who is willing 
to
accept those credentials.

> network is a closed infrastructure network and clients are not part of

Very valid observation ..

cheers,

--bk

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 15:50:27 -0400

Hi Brian,

I've tried to answer your questions based on my opinion only.

Certainly I don't want people to read anything into my
statements about an implied direction of the group ;)

> evidence that there is some consensus on how to go forward.

This is sufficient, but not necessary.
(It would do the job, but so long as we have agreement on the
scope of work, rather than the minutiae, there's no impediment
to forming a WG).

> are groups working on some, get a draft published, and let's look at them.

Let's not get bogged down now though.

If we identify an issue which isn't going to be resolved, let's flag
it for work when the group is being chartered.

> 1. Do we have consensus that P2PSIP, as would be defined by this group, is

my opinions only:

We should probably aim at identifying a set of requirements,
based on what we want rather than worrying about a technology.

I guess my take on it is that we know DHTs are likely to work.

Probably we should write a protocol which uses one DHT, as the
default incarnation (for interoperability), hopefully with enough
room to incorporate alternative technologies which also meet the
requirements.

> requirements a DHT needed to have in order to be acceptable?

I guess this is two questions.

2.a)
I think that we can design the protocol to be expanded to other
P2P structures or alternative DHTs if this doesn't compromise
the requirements.  Since we know this is a possible upgrade path,
we can keep it in mind when building the protocol.

A caveat would be that IMO we can't break the base protocol, for
a future need which may change or not eventuate, though.

2.b)

I guess that in internet terms, there will be network protection
(rate-limiting, no multiplicative attacks, etc) as
well as data protection (message integrity, potentially secured
transport), and robustness (bootstrap, fallback, authentication)
requirements.

There will also be structural requirements, such as what
infrastructure is assumed to be part of the network (such as
authentication services, bootstrap servers, etc).

Some of these things need high-level/architectural agreement
before we definitively mark them as requirements.

I hope this is helpful,

Greg

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Thu, 25 May 2006 15:31:09 -0400

Alan,

Oh, I absolutely didn't mean to imply it wouldn't be useful.  I think
it's very useful.  Key continuity is clearly useful, and the
voice-based SAS may well be the best option available for (voice) p2p
sip.  I was only observing that there are limitations to this approach
in terms of establishing initial identity and in terms of non-voice or
automatic systems that a CA system doesn't have.  (I'm basing this on
my reading of Zimmerman's FAQ and a quick read through the draft.)  I
think this is another example of it being useful to support different
authentication systems for p2p sip because different environments will
have different needs.

Bruce

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 16:02:01 -0400

Hi Mike.

Chartering a WG is the first step to _begin_ work in the IETF.

Stopping to talk about details doesn't help if there's no WG.

it's as simple as that.

Greg
Comments below

Mike Robinson wrote:
> On one hand, you are accepting  that you need time to understand 
> differences of DHT algorithms behavior and we need time to study that, 
> on the other you and your colleagues are saying there is need to chart 
> an IETF group for design of p2p sip and push a pre-mature design through 
> in a hurry.  Both can't be true since they are contradictory in nature.

We don't have to have the complete protocol before we charter!

A charter is an agreement on what work will be delivered.

One of the items is an analysis of what needs to be put in the protocol!

We know there are uncertainties and problems which will pop-up.

The issue is whether the group will be unable to apply existing
knowledge to the problem or not (research vs. engineering).

I'm firmly on the side that protocol engineering is the bulk
of the work.

> P2p DHTs in general belong to the  IRTF p2p group which already exists. 
> Any comparative work on DHTs belongs there, and unless that group 
> reaches some meaningful conclusions, proposing a p2p sip design, based 
> on a particular versions of DHT, is simply harmful to the interests of 
> every one except those who have vested interest to speedup adoption of 
> their view of the world.

I think you're confusing different classes of applications.
We have a small constrained goal:  distributing location URIs
without a single registration server.

This is a small chunk out of a very wide body of work.

As an example:
Not every part of packet-switching theory was mature enough to
standardize when IETF made the Internet.  Some parts are still
under development.

The trick is to Engineer a useful constrained subset.

This is standard operating procedure for the IETF.

This isn't about a research project people want to
standardize.  It's being done in a proprietary way today.

DHT based P2P location services are being done commercially.
DHT based P2P location systems scale to _very_ large networks.

Now is the time to stop the balkanization of these
peer-to-peer services, and provide an open standard.

> No one is even sure if sip is the right protocol for DHT management 
> except that someone thought so, or found it easier to code for whatever 
> reason.

No one has designed the protocol.
Dave's idea is a strawman.  There's no explicit tie to SIP from the
conceptual level. The details can be discussed when there's a WG.

Greg

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 25 May 2006 16:38:45 -0400

You seem to be making an assumption that there will be a charter, and the
charter will be accepted, and it might have a requirements document as one
of its charter items.

My impression coming out of the BOF was that unless we demonstrated a lot
more coalescing of ideas, what was on the table was not something the IESG
could get their hands around, and therefore, while it was clear there was
interest in doing "something" it wasn't clear what that "something" was.

List discussion so far has not convinced me, and I suspect the IESG, that we
have had much coalescing of ideas yet.

An agreed upon requirements list, whether it was in a fully baked draft or
just the big picture bullet list, would, it seem to me, go a long way
towards illustrating to the IESG that there IS enough of a consensus on what
to do that a WG could be chartered with the expectation that it would
produce something of value.

This thread is illustrating the issues.  There is a suggestion that there is
a requirement to have one mandatory-to-implement DHT.  I'm not at all sure
that is a realistic requirement, given the level of discourse so far, but I
sure would like to be wrong about that.  

If we don't think we could agree on one, then we would need to agree on some
other requirement, or we don't have any level of interoperability.

If there is no level of agreement on something that fundamental, I'm pretty
sure you can't get a charter that is accepted.

Brian

-----Original Message-----
Sent: Thursday, May 25, 2006 4:02 PM

Hi Mike.

it's as simple as that.

Greg
Comments below

As an example:

Greg

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 16:41:39 -0400

Hi Mike,

Mike Robinson wrote:
[cut]
> Unless someone can tell us clearly why sip should be used to create, 
> manage and re-configure DHT, the goal should remain a "proposed goal" 
> till then. IETF, or for that matter any standard organization should't 
> be a willing tool to fulfil any particular company's vested interests 
> (even when supposedly supported by  (a company  funded) researchers at a 
> University).

Only one of the (strawman) proposals says that SIP messages are used.
Alternative view on this have also been presented in the Ad-hoc sessions
leading up to the BoFs (and are still on the table).

There's no clear winner, there's not even a coalition of people who
have backed one.

Of course authors will each have points to make about their own ideas,
but that's why there's got to be a working group.  So the community
can work on the requirements and make sure that the best solution is
used.

If we didn't care about that, we'd just use/sell a proprietary system.

> urgency being shown to push a certain design without evaluating 
> alternative approaches. You don't  need standardization right away to 
> show that your model works- post your code to sourceforge.net and let me 
> see how good your design is by experimenting with it.

I think you've misread the situation.  There is code for at least
one implementation of a proposal available (is it on sourceforge?).

AFAIK, there's no-one here pushing a particular cart.

People here have a real desire to bring about the best system
for p2p sip.   There are people here willing to do the work
on assessing the protocol requirements, reviewing documents,
designing and building a protocol, following the IETF's
procedures.

If we just wanted to get something out commercially and push a
particular agenda, we'd have made an industry consortium.

It's a lot faster, it has more chance of success, and has less
inconvenient review.

Help us to charter the WG, because that's where the IETF can
have control of the outputs, and ensure protocol quality.

Greg

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 25 May 2006 16:51:18 -0400

Okay, so here we are again.  You are looking for an approved charter, and we
don't know what we are trying to do.

If there is consensus that this is to be a p2psip thing, then that's a whole
lot less work then if the sip part is still under discussion.

I'd go so far as to say, if it's NOT p2psip, then we are really in IRTF
land.

So, what is it?  p2psip or
p2p-some-kind-of-multimedi-session-control-protocol?

<hint - check the name of the mailing list>

Brian

-----Original Message-----
Sent: Thursday, May 25, 2006 4:42 PM

Hi Mike,

Mike Robinson wrote:
[cut]

Greg

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 16:52:48 -0400

Hi Brian,

I agree with you that we need a solid charter, and that
we need to discuss it well before going into the next
BoF.

I also know that the chairs and ADs, and a couple of others
(not me) are putting a lot of work into the charter right
now and have been doing so ever since Dallas.  There's been
radio silence as-yet on list, so the interested community
hasn't been able to see what rat-holes they've delved and
what progress they've made.

Really, I think it's a good thing that discussion has
started up on-list, and hopefully the chairs will be able
to contribute something soon, which will allow us to
debate it in good time, and develop our own consensus.

Just my opinion.
Greg

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 16:59:04 -0400

Hi Brian,

There's a distinction between P2P FOR sip and
P2P USING sip.

P2P FOR sip is a system which handles distributed
lookup of SIP location URIs,

P2P USING sip is a realization of how to do P2P FOR sip,
using SIP protocol (or SIP protocol-like) messages or
extensions.

There's broad agreement that we want P2P FOR sip
(the goal), but not necessarily agreement that
we need P2P USING sip.

This is not surprising, because the charter discussion
is about what we want to get done (P2P FOR sip),
rather than on exactly how to do it (e.g. P2P USING sip).

Clear now?

---

From: br at brianrosen.net (Brian Rosen)
Date: Thu, 25 May 2006 17:15:51 -0400

I'm sorry, I don't get it.

No one is proposing to use sip to do something equivalent to what a DHT
does.

Everyone is proposing to use sip messages to control session establishment.

A User Agent is going to send a pretty normal looking INVITE message.  The
question at hand is how it routes it.  It doesn't use the procedures in
3261.

I don't understand the difference.  I think that means I don't understand
what p2p using sip means.  As long as we are all agreeing that its sip
messages to do session management, at least I think we're in a do-able
situation.

Brian

-----Original Message-----
From: Greg Daley [mailto:gregd at research.panasonic.com] 
Sent: Thursday, May 25, 2006 4:59 PM
To: Brian Rosen
Cc: 'Mike Robinson'; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

Hi Brian,

Clear now?

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Thu, 25 May 2006 17:46:09 -0400

Hi Brian,

> I'm sorry, I don't get it.

I guess my cutting corners didn't help.

I'll try to be more explicit and we'll see if
there's a clearer picture emerges through discussion.

> No one is proposing to use sip to do something equivalent to what a DHT

There has been some discussion of sending P2P storage
mechanisms mapped onto existing REGISTER messages.
This is one of the P2P USING sip ideas I was trying
to touch on.

Setting up communications for a peer-to-peer
network using INVITEs etc, I agree are not proposed.

> Everyone is proposing to use sip messages to control session establishment.

Agreed.

> question at hand is how it routes it.  It doesn't use the procedures in

Actually, I think that the primary mechanism being proposed is
the location lookup service, similar to that provided
by RFC 3263 (though focussed on resolving the specific URIs
for a user, rather than the domain Proxy, if possible).

This may alter how registration is done (possibly adds a routine
to place the URI onto a DHT, for example).

How the INVITE/session-management signalling is routed is
another question.

Although there's been some discussion that SIP INVITEs can
be hop-by-hop routed across the DHT, that's not necessarily
the prevailng view (personally I'm against it).

INVITE is likely to go peer-to-peer directly (as the name
implies) with modifications only for ICE, or some "peerish"
additional parameters (again, I'd prefer none).  The routing
is compliant with RFC 3261, in that the message is routed
to the address contained in the location URI.

This address may be the UA's address though (so a P2P UA can
talk to another UA without going through a Proxy, perhaps).
Depending on the scenario, the address in the DHT (for example)
may point to an address at a proxy, instead.

In my guess the only reasons the SIP session management
signalling wouldn't go direct would be for NAT traversal
(SIP-Outbound/STUN Relay).

Of course, these are opinions, but they may illustrate
what I was thinking of for as the primary goal of P2P SIP:

Just a lookup service.

Try not to modify SIP for call-management messaging.

> messages to do session management, at least I think we're in a do-able

Definitely we use SIP messages for session management.

Personally, I'd prefer no modifications at all to those
messages.

Greg

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 25 May 2006 21:20:24 -0400

Sorry for the late response.

There has been some work on this issue. In fact, there is a draft that
generated a great deal of discussion. It came out back in October of
2005:

http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00.txt

Certainly wasn't complete, but I think most folks here agreed it was a
good start in that direction.

David

---

From: bryan at ethernot.org (David A. Bryan)
Date: Thu, 25 May 2006 21:29:32 -0400

A bit more clarification.

P2P over SIP means: "build a distributed lookup that SIP agents use to
locate each other, and use SIP messages to convey the
queries/organization for the distributed seach". The group would
standardize the extensions to SIP to do this.

P2P for SIP means: "build a distributed lookup that SIP agents use to
locate each other, but it may use other message formats (I've heard
SOAP proposed) to convey the queries/organization for the distributed
search" The group would standardize that other protocol

In both cases, the idea is regular SIP is used between the nodes. As
Greg points out, some (including my early work) proposed routing SIP
over the P2P layer as well. I backed off this a bit when many folks
objected in Vancouver, although I must admit that for NAT traversal
reasons, I'm liking it again.

This is list of several hundred people. People have proposed building
a generic multi-purpose DHT using SIP here, and people have proposed
replacing SIP here. It has seemed quite clear from the responses that
the majority of people do not agree with that, and that certainly
those of us trying to organize P2PSIP do not support those things.

--David

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Thu, 25 May 2006 22:46:01 -0700 (PDT)

> those of us trying to organize P2PSIP do not support

Agree 100%. The goal is not to produce yet another
DHT. The goal is to enable sessions between peers,
using SIP messages to set-up these sessions.

In fact, it seems that we have convergence on some
kind of two-phase approach:

1) Location: Given a SIP URL, find the IP address to
which SIP messages shall be sent;

2) Establishment: using SIP messages between the
peers, establish sessions, etc.

There are problems in both phases. In the location
phase, there are obvious issues of security (how does
Brian know he has located the real Henry), privacy (if
my friends can locate me easily, what about my foes),
and reliability (how do we protect against the Sybill
attack). In the establishment phase, the obvious
problem is NAT traversal.

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 26 May 2006 12:22:23 +0200

> one implementation of a proposal available (is it on sourceforge?).

(yes, it is)  At this point both written and coded proposals are only
meant to show that a solution is feasible.

There is a lot of discussion about the algorithm and the protocol for
DHT maintainance;  hey... are they really important, now?  If a WG were
formed people would be happily struggling for chord/kademlia/bamboo over
SIP/SOAP/RMI; until a WG is started, such arguements are only wasted time.

> AFAIK, there's no-one here pushing a particular cart.

There's no cart either; maybe someone's pushing a strawman, but not a
cart ;-)

Enrico

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Fri, 26 May 2006 12:27:26 +0200

> we need to discuss it well before going into the next

My opinion is that we still have a pretty good charter, which needs just
small changes according to issues raised during the BOF.

For facing concerns expressed by IAB and IESG members, we should clearly
assert that:
1. P2PSIP is not a replacement for SIP.  Instead its primary use is for
   extending SIP connectivity in environments where traditional SIP
   registrars/proxies cannot be practically deployed;
2. P2PSIP work will reuse existing IETF works (i.e. ICE for NAT
   traversal).  The charter was contraddictory on this point, but broad
   consensus for fixing it was found during the BOF;
3. P2PSIP group will not do research work.  The goal of distributing
   functionalities for lookup and NAT traversal will be achieved
   using existing and well-known algorithms.

The ambiguity of the term "P2P" and the appeal of Skype-like solutions
(which for many reasons _won't_ be standardized in IETF) may have
obfuscated those key points, worring ADs and IAB members.  IMHO the
changes needed are not so drastic and the group would quickly agree on them.

Enrico

---

From: henry at pulver.com (Henry Sinnreich)
Date: Fri, 26 May 2006 08:40:00 -0500

Maybe we should all talk using the same reference material, such as:

http://opendht.org/pubs.html 

and then we can discuss the issues item by item, such as routing modes,
response time, delay aware routing, partial search, etc. 

Last but not least open running code and experimental results. Clearly SIP
has not been designed to address these issues and there is no reason to
duplicate all this work.

Any opinions on the technology at http://opendht.org/pubs.html ?

Publications Related to OpenDHT

Distributed Segment Tree: Support of Range Query and Cover Query over DHT.
Changxi Zheng, Guobin Shen, Shipeng Li, and Scott Shenker. 5th International
Workshop on Peer-to-Peer Systems (IPTPS 2006), February 2006. 

Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. Sean Rhea,
Byung-Gon Chun, John Kubiatowicz, and Scott Shenker. Proceedings of USENIX
WORLDS 2005, December 2005. 

Non-Transitive Connectivity and DHTs. Michael J. Freedman, Karthik
Lakshminarayanan, Sean Rhea, and Ion Stoica. Proceedings of USENIX WORLDS
2005, December 2005. 

OpenDHT: A Public DHT Service and Its Uses. Sean Rhea, Brighten Godfrey,
Brad Karp, John Kubiatowicz, Sylvia Ratnasamy, Scott Shenker, Ion Stoica,
and Harlan Yu. Proceedings of ACM SIGCOMM 2005, August 2005. 

A Case Study in Building Layered DHT Applications. Yatin Chawathe, Sriram
Ramabhadran, Sylvia Ratnasamy, Anthony LaMarca, Scott Shenker, and Joseph
Hellerstein. Proceedings of ACM SIGCOMM 2005, August 2005. 

Spurring Adoption of DHTs with OpenHash, a Public DHT Service. Brad Karp,
Sylvia Ratnasamy, Sean Rhea, and Scott Shenker. Proceedings of the 3rd
International Workshop on Peer-to-Peer Systems (IPTPS 2004), Springer-Verlag
Lecture Notes in Computer Science Hot Topics Series, San Diego, CA,
February, 2004. (The OpenDHT project was originally titled "OpenHash".)

Thanks, Henry 

-----Original Message-----
Sent: Thursday, May 25, 2006 8:30 PM

--David

On 5/25/06, Brian Rosen <br at brianrosen.net> wrote:
> > Okay, so here we are again.  You are looking for an approved charter,
and
> we

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 26 May 2006 11:50:58 -0400

Hi Henry,

So obviously everyone here knows I've got a bit different approach,
and there are a few things about an OpenDHT approach I don't
understand.

I think that my biggest concern is that using OpenDHT, I can only see
how to address some of the use cases proposed. In the use cases draft,
I can't see how an OpenDHT approach could solve the scenarios in 3.2,
3.3 or 3.4, only how to use it to solve 3.1

I also don't see what it is this group would standardize if we use
OpenDHT. I don't think this WG is the right place to standardize
OpenDHT -- that certainly wouldn't be P2PSIP, but rather a general P2P
working group. My idea for this group is to build a specialized,
limited to SIP, light weight P2P mechanism, so that we can have many
interoperable UAs from different vendors/open source development
teams, all locating resources using P2P mechanisms, and not dependent
on external agents for that resolution (only the UAs themselves,
possibly not connected to the big-I Internet). In other words, we
specify an alternate location protocol for SIP between the devices
themselves.

Am I just confused about OpenDHT?

David

---

From: henry at pulver.com (Henry Sinnreich)
Date: Fri, 26 May 2006 11:33:23 -0500

The DHT layer can be (1) inside the SIP Peer UAs as suggested by Eunsoo
Shim:

http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt

See Fig. 2

...or (2) just to start, one can use openDHT as an emerging _DHT service_.

I guess we need to evaluate the criteria what to use in the DHT layer. 
SIP in the DHT layer is wrong IMHO. This is explained in:

http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt  

Thanks, Henry

-----Original Message-----
Sent: Friday, May 26, 2006 10:51 AM
To: henry at pulver.com

Hi Henry,

David

On 5/26/06, Henry Sinnreich <henry at pulver.com> wrote:
> > >> (even when supposedly supported by  (a company  funded) researchers
at
> a

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Fri, 26 May 2006 12:56:57 -0400

Hi Enrico,

Enrico Marocco wrote:
[cut]
> meant to show that a solution is feasible.

Can you please repost the URL?

> SIP/SOAP/RMI; until a WG is started, such arguements are only wasted time.

Arguments certainly may be a waste of time now.

If we start contributing requirements, this may help though.
Having implementation experience certainly helps there.

> There's no cart either; maybe someone's pushing a strawman, but not a

That's OK, so long as it's not a brick man. ;)

Greg

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Fri, 26 May 2006 13:00:12 -0400

Hi Enrico,

> changes needed are not so drastic and the group would quickly agree on them.

I agree that the charter was in fairly good shape, and
I hear is developing to address some of those issues
(I like your text though).

But there's no predicting mailing list discussion...

Greg

---

From: alan at sipstation.com (Alan Johnston)
Date: Fri, 26 May 2006 12:32:51 -0500

David,

Your reply seems to suggest that you think a single DHT will solve all 
these use cases.

I believe that concentrating on a single DHT or other P2P technology is 
not a good idea.  Also, I'm a little uncomfortable signing this group up 
to designing or implementing a specific DHT algorithm.

Instead, I think this IETF group should concentrate on defining 
protocols on the wire.  I'm still putting my thoughts together and will 
detail them in a draft soon, but rather than standardizing a particular 
DHT, we need to define an RFC 3263-like document that describes how SIP 
UAs can utilize a P2P Location Service.  This would include a protocol 
for how things like Contact URIs, certificates, presence data, etc. can 
be pushed and retrieved from a DHT.

With a standard protocol defined for this interaction, any DHT 
implementation or technology could implement this interface and be 
usable for P2P SIP. 

We would also need to define some discovery mechanisms, as well.

Perhaps with a clear scope like this in our charter we could get our 
working group going.  Once this basic work is complete, we can start 
discussing the merits of one DHT vs. another, and also perhaps 
architectures, although P2P SIP architectures might be better done 
somewhere like the SIP Forum.

Look for a more detailed proposal to come...

Thanks,
Alan

David A. Bryan wrote:

>>>Everyone is proposing to use sip messages to control session
>>>      
>>>
>>establishment.
>>    
>>
>>>>If there is consensus that this is to be a p2psip thing, then that's a
>>>>        
>>>>
>>>whole
>>>      
>>>
>>>>>(even when supposedly supported by  (a company  funded) researchers at
>>>>>          
>>>>>
>>a
>>    
>>
>>>>>University).
>>>>>          
>>>>>
>>>>>show that your model works- post your code to sourceforge.net and let
>>>>>          
>>>>>
>>me
>>    
>>

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Fri, 26 May 2006 21:28:05 +0200

I also support Alan's idea of an "RFC 3263-like document" which  
allows standard SIP peers to locate each others using structured or  
unstructured overlays.

The goal of the WG should be:

Allowing standard SIP sessions between end-points by using either:

1. Central naming and addressing authority like DNS
2. P2P self-organizing network overlay

while preserving interoperability between the two models.

The overlay implementation should remain an implementation issue, the  
work must be directed to standardize an API between SIP end-points   
and the overlay. Like the DNS query and response pair.

Adrian

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Fri, 26 May 2006 18:07:58 -0400

Hi Alan,

> implementation or technology could implement this interface and be 

One of the underlying assumptions of RFC3263 is the presence of DNS,
and this provides a single interoperable message query fabric available
to discover SIP locations.

To assume things will work if there is not an interoperable query fabric
which will be able to be used (at least by default) by P2P-SIP nodes is
probably incorrect (unless we say fall back to CS/SIP), which can use
DNS.

I also agree that the group should focus on message formats and
behaviours for the location service.

I'm not proposing research into DHTs. I think that most of the DHTs
people have been talking about, Chord, Pastry, etc, are different ways
of cutting the same cake.  It really doesn't matter which we pick, so
long as the effort to design and secure such a protocol isn't exacerbated.

> We would also need to define some discovery mechanisms, as well.

Sure, but let's try to use existing methods where possible.

> somewhere like the SIP Forum.

I agree that discussion of one DHT over another is for later.

Really, we need enough architecture to get the initial work
going here, without relying on another body to crank up an
effort, though.

Greg

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Sat, 27 May 2006 10:38:45 +0200

> Can you please repost the URL?

http://sipdht.sourceforge.net

Repository and snapshots are ok; mailing list doesn't work yet.

Agreed.

Enrico

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Sat, 27 May 2006 12:15:27 +0200

Henry,

> ...or (2) just to start, one can use openDHT as an emerging _DHT service_.

Is an external DHT service really different from a traditional location
service (e.g. a SIP registrar or a dynamic DNS service)?  I can
understand it only as a temporary solution; if the location service
wasn't distributed across SIP UAs, would this work have any real value?

> http://www.p2psip.org/drafts/draft-shim-sipping-p2p-arch-00.txt  

Perhaps you mean:

The list in sec. 8 is arguable IMHO, but now it's not time for
discussing how to transport bits.

BTW: I've missed some messages and have had to look for them on the
archive; does anyone have encountered the same problem?

Enrico

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 29 May 2006 00:06:30 -0400

Hi Enrico,

> wasn't distributed across SIP UAs, would this work have any real value?

There are two logically distinct roles:

SIP UA (perhaps with the ability to access the P2P location service)

and

distributed P2P location storage (for example, using DHT).

These may end up being on the same box, but there's no
logical constraint for them to be.  I mean: it's just a
data storage service, for small blobs of data.

> discussing how to transport bits.

Actually, I think he meant the former.

Greg

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 29 May 2006 12:38:08 +0200

> data storage service, for small blobs of data.

Sure, but what could be achieved using a free storage service such as
OpenDHT could also be achieved using a free conventional SIP provider or
a free dynamic DNS service (e.g. dyndns.org).  Instead, the most
relevant use-cases for which conventional SIP doesn't work require the
Location Service to be distributed among some/all of the SIP phones;
such a solution should be the main goal IMHO.

>>> I guess we need to evaluate the criteria what to use in the DHT
>>> layer. SIP in the DHT layer is wrong IMHO. This is explained in:
>>>

I should have read it more carefully ;-)  Alan's draft explicitly lists
issues with P2P SIP implementations (sec. 8 "SIP P2P Implementations");
can you please point out where it is explained in the architecture draft?

Enrico

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Mon, 29 May 2006 23:55:39 -0400

Hi Enrico,

Enrico Marocco wrote:
[cut]
> such a solution should be the main goal IMHO.

It's not about OpenDHT.  I think it was being discussed for
illustrative purposes.

One of the primary reasons people may want a logical separation between
the overlay infrastructure and SIP, is because most Infrastructure SIP's
not all about NAT traversal services, while P2P infrastructure services
(which may just happen to be running on publically addressed SIP
devices) may be heavily involved.

Does someone have to implement the full SIP stack to run a STUN Relay?
How about providing a robust way to discover these Relays, and
distribute loads, etc?  Is SIP required for these functions?

I'd guess not.

So if the function of the NAT traversal services aren't necessarily
tied to SIP protocol, why would the distributed lookup service?

Now, if the protocol does end up being SIP or SIP-like, that's OK,
it's just that architecturally, it's not needed.

> can you please point out where it is explained in the architecture draft?

Do you mean apart from section 3: Architecture Overview, which starts:

    A peer in the P2P SIP system is comprised of two layers: the P2P
    overlay layer and the SIP layer.  The P2P overlay layer handles all
    the P2P overlay functions.  The P2P overlay layer does not interpret
    semantic meanings of the resources placed or looked up by the higher
    layers including SIP.  But its design goal is serving SIP and thus
    SIP-based real-time media applications.  That is, other applications
    may use the P2P overlay layer presented here but the architecture and
    the algorithm used for this P2P overlay layer may not necessarily be
    optimal for all applications.

Sure this is our take on it, but the tie between the P2P lookup function
and SIP is, at best, one of convenience.

Greg

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 29 May 2006 22:44:53 -0700

One of the things that was confusing to people at the last BOF was  
what were you trying to standardize. Presumably the purpose of the a  
standard would be so that two different vendors could implement  
something that they would work together.

Now I have tried to listen to the whole conversation and let me point  
out something that has caused me confusion. An architecture that we  
are tying to move away from with this work is that all the UAs  
connect to a proxy farm. The proxy farm has some complex and  
proprietary way to of sharing the state so that the UAs can find  
other UAs. This has central servers that, as Henry points out are  
expensive because of the support staff they imply which implies a  
spiraling circle of things this work is trying to avoid.

Now the group is sticking with the idea that there is some sort of  
SIP location database and perhaps distributed TURN servers. However  
this would be stored in a DHT (or something like one). The storage  
would be distributed across a bunch of nodes that participated in the  
storage. Now we come to what I see as the first critical question of  
what is this group proposing to do. Who can build one of these nodes  
that participates in the storage of the location database  
information? If your answer is they all have to come from one vendor  
and speak a proprietary protocol, then I don't really see why this  
will be different from the model above that we are trying to avoid  
and I don't see who will run these, and furthermore I don't see what  
standardization is needed. I do not object to this path if this is  
where the group wants to go but theses are some of the next level  
down questions to answer on this path.

An alternative path is that more than one vendor can build the things  
that participate in the DHT or store the location database  
information and that in some cases they same devices or computer that  
is the end UA will also have participate in this way. This answers  
the question of who will deploy and build these - everyone will and  
the end users will scale the location database storage as they  
connect more devices to the system. Who will run them will be the end  
users. However, it opens another set of questions. To do this you  
will need to standardize some DHT or set of DHTs like things and the  
protocols to update and mange them as well as store and retrieve  
information in them. I believe you could specify some protocol to  
build a DHT for the location database purpose and base it on some  
simple DHT today and include enough capabilities information that it  
could negotiate to different or more complex DHTs in the future. I  
find it easier to understand how this path will reach the goals we  
want of not having reliance on central providers for complex services  
- this may just be I don't understand the other path well enough and  
need to have it explained to me. I have asked but have not heard many  
answers yet.

I have many more question down each branch of this tree but I think  
the high order bit is "who do we expect to run the servers that store  
information in the DHT". One answer is a central provider. The other  
answer is the users of the system. We need a crisp decision on this.

Cullen (with my individual contributor hat on)

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 30 May 2006 12:19:21 +0200

Greg,

I think we are saying the same thing.  Let's clarify...

> devices) may be heavily involved.

I'm also for a clear separation between SIP and the overlay and I've
been so since the early days of P2PSIP.

> distribute loads, etc?  Is SIP required for these functions?

Just in case SIP were chosen for implementing the overlay layer too, but
this group doesn't seem to love much such option ;-)

> it's just that architecturally, it's not needed.

I'm not pushing SIP for the distributed lookup service; instead, I'm
saying that whatever the protocol will be, it MUST be possible to embed
it in SIP boxes, not only for accessing the lookup service, but also for
participating in its distributed implementation.  A solution which
relies on an external lookup service like OpenDHT doesn't allow the latter.

> and SIP is, at best, one of convenience.

I perfectly agree with the text and I also like the proposed
architecture; however, I think that a SIP-based DHT - the one described
in draft-bryan-sipping-p2p-02 is an example - is suitable for being
adopted as the SN-SN protocol of the P2P layer.
Does your draft discourage this?  Alan's one does and I think Henry's
referring to it.

Enrico

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 30 May 2006 12:57:54 +0200

> answer is the users of the system. We need a crisp decision on this.

Off course there is broad consensus for the latter.

I think nobody really wants to rely on a central provider for storing
information; someone - mainly Alan and Henry - are proposing to begin
with the definition of a Location Service Protocol, which could be
implemented from both external and P2P DHT-based services.  The group
would then focus on the definition of some protocols to let SIP devices
build such DHTs.

Actually, I think the strongest consensus is only for the second part,
but it's just a feeling.

Enrico

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 30 May 2006 09:20:51 -0700

"A cat is good as long as it catches mice."

Me dont think SIP good (economic) for transporting all kind of services on
DHT, unless P2P SIP will be just for "vanilla" sessions. We may need to
store various kinds of databases distributedly so need a slim protocol to
access various kind of database objects without worry of MTU like we are
(Netrake SBC MTU=1300). I sincerely hope for some kind of simple binary
encoding protocol like SS7 IEs from the start so that we wont have headache
on SigComp.

Please be realistic. Different DHTs can't interoperate on peer-to-peer
basis; they can, only via gateway. I sincerely propose Kademlia since
eMule/eDonkey have proved it work (and I chose it :)

Please be specific. At least be specific to start defining some comformance
levels on what to do (functionalities/features) and how to do
(protocol/overlay). Being specific helps make derived products in small
footprint. Being specific does not mean less ambitious and simple but
confident and simplex to avoid us (you) from wavering around the same point
on the today of 2007 or 2008 watching Skype gulping millions of users every
month (:

PP
----- Original Message -----
From: "Greg Daley" <gregd at research.panasonic.com>
To: "Enrico Marocco" <enrico.marocco at telecomitalia.it>
Cc: <p2p-sip at cs.columbia.edu>; <henry at pulver.com>; "'David A. Bryan'"
<bryan at ethernot.org>
Sent: Monday, May 29, 2006 8:55 PM
Subject: Re: [p2p-sip] P2PSIP, Kademlia and caching

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 30 May 2006 12:46:22 -0400

> would then focus on the definition of some protocols to let SIP devices

I agree with Enrico.
The motivation of the proposal of using OpenDHT (or any public DHT
service) for most, if not all, people who are talking about it is that
it will be easier for the proposed WG to start with the work of
designing the access protocol (basically GET/PUT messages between the
UAs and the DHT nodes and then work on the more difficult DHT protocol.
I used to call the former the ON-SN protocol and the latter the SN-SN
protocol (GET/PUT/JOIN/LEAVE).

I believe that there is a strong consensus that eventually P2PSIP users
should be able to build their own P2PSIP network without relying on any
centralized provider.

So the issue is whether we will work on two protocols in parallel or
sequentially in my understanding but not whether we will enable UAs to
participate in a DHT.

My preference is that we put both protocols as deliverables in the
initial charter but plan to finish the access protocol before the other
protocol.

Thanks.

Eunsoo

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 30 May 2006 12:45:29 -0400

Hi Enrico,

We're in violent agreement.

Just answering the final question...

Enrico Marocco wrote:
[cut]
> Does your draft discourage this?  Alan's one does and I think Henry's

I don't think our draft explicitly discourages anything,
but it did make assumptions (even having record formats, etc).
Sathya's fixing this up for the next revision.

It did concentrate on the separation of lookup and SIP, for the
reasons mentioned earlier.

Greg

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 30 May 2006 10:25:43 -0700

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.

---

From: alan at sipstation.com (Alan Johnston)
Date: Tue, 30 May 2006 12:39:52 -0500

>of the two. So if we look at our end goal, is there a need for GET/ 
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?  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.

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.  To do both of these efforts them at the same time makes no sense 
to me.

Thanks,
Alan

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 30 May 2006 14:01:56 -0400

What do you have in mind as far as what is to be pushed/pulled? I know
there have been discussions here of registration, and possibly
locations of peers capable of functioning as relays. Are you thinking
VM here? Arbitrary data?

Agree what we store could influence the design. If we put too much in,
we are however rapidly approaching a generic DHT, which while cool,
wouldn't really be P2P SIP anymore.

David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 30 May 2006 15:07:51 -0400

> this?  Think wireless, low bandwidth, and embedded UAs.  

An excellent explanation. There is a need to package just GET/PUT into a
protocol even though the DHT protocol contains GET/PUT as well as
JOIN/LEAVE.

It is too early to talk about syntax of the protocols but in general the
GET/PUT only protocol may or may not have the same syntax as the DHT
protocol. Depending on the detailed design, the GET/PUT only protocol
specification may be just a subset of the other protocol's specification
or may be a completely different protocol.

> only somehow choose one single DHT and standardize it that we will loose.
I think there is also a consensus that the DHTs (or P2P overlay
technologies) are evolving continuously and the proposed WG should not /
cannot decide which DHT is the best but it is not wise either to wait
until someone picks the best DHT algorithm for us or it becomes certain
no new better DHT algorithm will appear.

So what has been proposed was that we need to pick at least one DHT
algorithm but may pick more (not many but just a few) later so that we
can have implementation, experiments, and interoperability. I think we
all agree that there is no DHT algorithm fitting all scenarios the best way.

Since the call setup logic and the DHT function are separate and quite
independent, by a proper modular architecture, we will be able to adopt
new DHTs (or other P2P algorithms) fairly straightforwardly or at least
without breaking too many things.

> layer.  

I agree. This is another important deliverable. So we have three key
deliverables:
(1) the GET/PUT only protocol
(2) the GET/PUT/JOIN/LEAVE protocol (a DHT)
(3) Information to be stored at and retrieved from the DHT, how it will
be handled. (This may include some basic call procedures.)

Another deliverable proposed and stressed so far was
(4) how to find proper (close) media relays or STUN relays.

I think (3) and (4) are or can be independent of the selected DHT
algorithm as long as the DHT algorithm meet the requirements. That is,
we can change the underling DHT algorithm without breaking (3) and (4).
We may have even (1) independent of the DHT algorithm choice.

For (1) and (2), the basic functions are all well-understood. But what
security and reliability features we want will have significant
influence on the protocol specifics.

To do both of these efforts them at the same time makes no sense
> to me.
Hmm.. Alan is proposing to put a minimum set in the initial charter
while I am somewhat liberal about it.

Thanks.

Eunsoo

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Tue, 30 May 2006 15:09:25 -0700

On May 30, 2006, at 10:39 AM, Alan Johnston wrote:

>> I'll be very blunt about doing both proposal. It is not clear to  
>> me  if people think we should do both because
>> 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.

> 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.

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Wed, 31 May 2006 00:58:12 -0700 (PDT)

> standardized a P2P protocol but I don't see how we

The classic DHT protocols are optimized to publish
many hash indices on a relatively smaller number of
nodes. This is the basis for the "PUT" primitive: find
the node most appropriate to publish a given index.
The typical use is a large database, in which each
node holds thousands of records. Much efficiency is
gained by pushing the indices of these records at the
nodes with the closest ID. In such networks, the
overhead of maintaining a "routing table" between the
nodes is not much of a concern.

P2PSIP has a very different structure. The average P2P
SIP UA publishes exactly one SIP URL. In these
conditions, there is not much value in the "PUT"
primitive. The SIP URL is the node's ID, so the PUT is
a strictly local operation. The DHT for the P2PSIP
application will typically operate with "one record
per node". Routing overhead is going to matter a lot.
Designs like Chord or Pastry may be seriously
suboptimal.

-- Karst

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 31 May 2006 16:56:19 +0200

Cullen Jennings wrote:
> 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.

No, there isn't.  Moreover, aren't IMS Cx, Dx and Sh interfaces (based
on DIAMETER) a superset of the G/P you are talking about?  I think it
would be an error submitting a charter with such a goal.

The group should instead focus on (unordered):
+ defining the general architecture which would let canonical and P2P
  SIP interoperate;
+ defining a DHT negotiation mechanism;
+ defining some discovery mechanisms;
+ defining some DHTs for different usages (e.g. in ad-hoc networks,
  metropolitan wlans...).  The more advanced/structured they are, the
  more generally adopted they will be; the more basic, the more
  specifically.

My 2 cents.

Enrico

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 31 May 2006 10:58:53 -0400

I think it is very unlikely that the URL will be the node's ID. In
fact, you explicitly want users to be able to choose a URI of some
meaning (hopefully more meaning and easier to remember than a phone
number, which a 160 bit Node ID certainly isn't), while a node ID
should (to prevent many of the placement of a node in the overlay
based attacks on DHTs) be random and not chosen by the user.

I agree it is likely a user will publish one record per node, although
it may refresh it periodically, and redundancy may lead to storing on
average more than 1 item per node (likely n where n is the number of
mirrors of each registration you store for redundancy).

All of this assumes a flat architecture, of course. If you used a
supernode type structure then obviously you might have many
registrations per DHT node. If other information is stored beyond
registrations, as people have mentioned doing in the future, that
would also increase the items being stored by each node.

--David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 31 May 2006 11:29:10 -0400

Karst Bjorgson wrote:

>primitive. 
I guess you mean publishing user location information (URL -> IP address
mapping) by 'publishing a SIP URL'.
User location information is certainly the most important information to
be published in the P2PSIP network but not the only one.
We can imagine easily that P2PSIP networks need to support presence
information and VM exchange between users which might be done via the
P2P network as well.

>The SIP URL is the node's ID, so the PUT is
>a strictly local operation. 
>
I am not sure I understand this.
How does a caller find the mapping of URI to IP address if the mapping
is not published using the DHT PUT operation?

>The DHT for the P2PSIP
Thanks.

Eunsoo

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Wed, 31 May 2006 11:53:42 -0400

----- Original Message ----- 
From: "Enrico Marocco" <enrico.marocco at telecomitalia.it>

>  more generally adopted they will be; the more basic, the more

For a small  network, a DHT is not needed - one can create a simple table of
SIP URIs and node mapping,  or learn such a mapping through a simple service
discovery protocol (use SLP, UPnP (SSDP) or other networking means (Dynamic 
DNS,
DHCP, Radius  Extension etc.)).

I think the real benefit of DHT is in scalability - so if the scale does not 
require
a DHT, it makes little sense to have one since you can have lot simpler
implementation in your nodes.

cheers,

--bk

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 31 May 2006 12:07:45 -0400

Cullen Jennings wrote:

>>> want the later  of the two. So if we look at our end goal, is  there
>>> a need for GET/ PUT only.
>>>
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.

>> To do both of these efforts them at the same time makes no sense to  me.
>
> Agree here too.
>
Thanks.

Eunsoo

---

From: ggb at tid.es (Gustavo García Bernardo)
Date: Wed, 31 May 2006 18:39:10 +0200

> implementation in your nodes.

It think the benefit is not only scalability, there are other benefits as
easy deployment and robustness for example.  I think DHT is also useful in
small networks.

Regards

G.

---

From: bk9001 at gmail.com (Brijesh Kumar)
Date: Wed, 31 May 2006 13:55:11 -0400

----- Original Message ----- 
From: "Gustavo Garc?a Bernardo" <ggb at tid.es>
To: "'Brijesh Kumar'" <bk9001 at gmail.com>; "'Enrico Marocco'" 
<enrico.marocco at telecomitalia.it>; "'Cullen Jennings'" <fluffy at cisco.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Wednesday, May 31, 2006 12:39 PM
Subject: RE: [p2p-sip] What are we doing - question 1

> easy deployment and robustness for example.  I think DHT is also useful in

Gustavo:

It appears there is divergence in the definition of "small".

Basically,  I don't see how registration and recovery of SIP URI and 
corresponding node IP address
in a DHT is any different than basic service discovery in which a node 
registers its services so that
other nodes in the network can learn about those services.

There are a number of  service discovery protocols that would work within an 
enterprise of reasonable
size with quite robustness.  As a matter fact, SSDP (UPnP) and  SLP, both 
support fully distributed
service discovery and do support a reasonable size network within an 
enterprise. So  if you can use them
for general service discovery, and believe they are robust enough, there is 
no  reason they can't discover
SIP URI and node-IP address mapping since that's all you need to enable p2p 
Sip within a "small" network.

Let me clarify that I am not saying that one cannot build such a solution 
using DHT or use service discovery
protocols to enable p2p sip, but only saying that DHT is not an absolute 
requirement, and there may be
simpler approaches for people trying to enable p2p sip in a very "small" 
ad-hoc networks.

cheers,

--bk

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 31 May 2006 17:13:27 -0700

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

> So now we have two interfaces.
|<---------------------------------------->|<-------------------------------
----------------------->|
me.

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 31 May 2006 19:32:12 -0700

On May 31, 2006, at 8:53 AM, Brijesh Kumar wrote:

> discovery protocol (use SLP, UPnP (SSDP) or other networking means  
> (Dynamic DNS,

I probably misspoke in my use of the word DHT. What I really meant  
was the placeholder for whatever it was that formed the distributed  
database. I did not mean to rule out something like broadcast of all  
the data to all the nodes being one of the approaches to this (or  
others that you mentioned).

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Wed, 31 May 2006 19:33:55 -0700

One trivial comment and one important comment inline...

> nodes, the number becomes around 20.

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. 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.

> simple maintaining connections with fingers and other nodes for which

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.

> |<---------------------------------------->| 
> <------------------------------------------------------>|
>              (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?

---

From: ekr at networkresonance.com (EKR)
Date: Wed, 31 May 2006 08:54:32 -0700

Cullen Jennings <fluffy at cisco.com> writes:

> is the end UA will also have participate in this way.

Certainly, the question of whether the protocol is interoperable is
important one, but I think there's another important one you're
missing: are the various participants inside the same trust domain?

-Ekr