Subject: Re: [P2PSIP] Who is working on an implementation for a P2PSIPproposal?

From: <[email-masked]>
Date: Tue, 9 Oct 2007 16:11:12 +0530

Is HIP-HOP implementation will be based out of following draft ?? Or
there will be any further updations to it ??

http://www.ietf.org/internet-drafts/draft-matthews-p2psip-hip-hop-00.txt

-chetan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 27, 2007 9:31 PM
To: [email-masked]
Subject: P2PSIP Digest, Vol 9, Issue 25

Send P2PSIP mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/p2psip
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of P2PSIP digest..."

----------------------------------------------------------------------
The group behind the HIP-HOP proposal has an implementation planned. The
approach we are taking is to write a -00 draft of an I-D describing an
aspect of the proposal first, and then implement the result. In our
opinion, there is a certain discipline that comes from writing an I-D;
it forces you to think more about what you are doing. For example, it
forces you to argue for your design choices and forces you to think
about the security implications of your design. We plan to write an I-D
before starting our implementation, and then use the feedback from the
implementation to revise the I-D.

In our case, we are planning to base our implementation on an existing
HIP implementation, since HIP-HOP is an extension to HIP. Initially,
this will likely be the Ericsson HIP-for-BSD implementation, though we
are also investigating the OpenHIP implementation and may choose to do
two implementations. Both of these HIP implementations are available
today.

The current HIP-HOP document describes a high-level architecture. We are
currently working out the details on some of the aspects of this design
before writing an I-D.

- Philip

Message: 1
Date: Thu, 27 Sep 2007 09:50:52 -0400
From: [email-masked]
Subject: [P2PSIP] Out of Office
To: [email-masked]
Message-ID:
	
<48c491b5c0b5453699592539dee85bad@2fcd6b8b14534629b4a69e841de77654>
Content-Type: text/plain;	charset=iso-8859-1

Hello,

I am out of the office and will be unable to respond to messages until
Monday.

Claude

------------------------------

Message: 2
Date: Thu, 27 Sep 2007 16:29:53 +0200
From: "Jan Seedorf" <[email-masked]>
Subject: Re: [P2PSIP] Who is working on an implementation for a
	P2PSIPproposal?
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Dear Mosiuoa and all,

I supervise a thesis at the University of Hamburg where we actually use
the the same componenents to build a P2P-SIP prototype: OpenChord as a
DHT and JAIN-SIP to build a SIP-to-DHT-Adaptor. It works fine (tested
only with softphones so far). Our focus is security: we intend to
measure how much delay certain security add-ons (either on the DHT layer
or on the application/SIP-layer) add to the total call setup-time. From
a security perspective we believe that the real-time demands for VoIP
may yield certain DHT-security techniques more suited for P2P-SIP than
others. Exploring this area is the core of our work.

Mosiuoa: if you are interested in exchanging experiences etc. send me an
e-mail, I am interested in your experiences so far. Specifically, we had
some (minor) problems with iterative routing in OpenChord, some of which
have been fixed in the latest release.

Kind regards,
Jan

-----Original Message-----
From: Mosiuoa Tsietsi [mailto:[email-masked]]
Sent: Tuesday, September 25, 2007 5:05 PM
To: Adrian Georgescu
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Who is working on an implementation for a
P2PSIPproposal?

Hi,

We at Rhodes University in South Africa have implemented a design for a
P2P SIP node based on the OpenChord and Bamboo DHTs. Its basically
middleware between the application logic and the underlying SIP stack.
For proof of concept, we incorporated this layer into a VOIP client from
NIST labs which embeds a JAIN stack. We have not been able to push out
an ID yet, but are planning to - but alot of the ideas that have been
criss-crossing on this list have fed into the implementation i.e. DHT
agnosticism (overlay pluggability), SIP-over-P2P, separation of P2P
layer from service layer (pluggable services), use of DynDNS for CS
SIP-P2P SIP interoperation etc; Hope to submit something soon just to
communicate ideas and experiences. 

Mos

On 9/25/07, Adrian Georgescu <[email-masked]> wrote:

	AG Projects is also providing infrastructure solutions for self-
	organizing SIP Proxies by using P2PSIP concepts.
	
	Adrian
	
	On Sep 25, 2007, at 4:32 PM, Bruce Lowekamp wrote:
	
	> SIPeerior has a full P2PSIP that is for sale now and is being
used by 
	> real-world customers.
	>
	> There are some slight differences between the commercial
version and
	> RELOAD, mostly due to lessons learned from one being
incorporated into
	> the other at different times. 
	>
	> Bruce
	>
	>
	> On 9/24/07, Hannes Tschofenig <[email-masked]>
wrote:
	>> Let's just ask the group: Who has done implementation work
(or is 
	>> planning todo some implementation work) with regard to a
proposal
	>> discussed in this group?
	>>
	>> Ciao
	>> Hannes
	>>
	>>
	>> Peter Pan wrote:
	>>> not just "when and how" but also "who and whether", i think:

	>>>
	>>> may we know who are working on p2psip implementations (both
	>>> private and
	>>> open-source)?
	>>>
	>>> how can we know whether yours are comprehensive (competent, 
	>>> independent,
	>>> interoperable, operational, ... ) or not?
	>
	> _______________________________________________
	> P2PSIP mailing list
	> [email-masked] <mailto:[email-masked]> 
	> https://www1.ietf.org/mailman/listinfo/p2psip

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

------------------------------

Message: 3
Date: Thu, 27 Sep 2007 17:46:56 +0200
From: "Mosiuoa Tsietsi" <[email-masked]>
Subject: Re: [P2PSIP] A DHT question on peers running out of storage
To: "Spencer Dawkins" <[email-masked]>
Cc: P2PSIP Mailing List <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi again,

If we assume that the overlay refuses to store the key because the
correct root of the key is unable to  hold it due to exhausted storage
capacity, then we find ourselves in a similar situation that skype did.

However, if we allow the root of the key to delegate the key to another
adjacent node, it probably must maintain state about that (some pointer
that is lighter than storing the actual resource), otherwise, how do we
differentiate between a key that doesn't exist in the overlay anymore
(i.e.
a node that has since resigned and had its binding removed from the
overlay) and a key that is on the adjacent node? Otherwise, we find
ourselves 3XX'ing for stuff that's not there anymore.

Taking a step back though, I think it's unlikely to happen.  If the only
nodes that store keys are the peer nodes then I think constraints are
put on them to have enough storage to implement the location service.

My thots,

Mos

On 9/27/07, Spencer Dawkins <[email-masked]> wrote:
>
>  Does the "not enough storage" peer remember specific key/value pairs 
> that have been stored on an alternative peer, or just 3XX everything 
> it doesn't find locally to the same alternative peer?
>
> Spencer
>
> ----- Original Message -----
> *From:* Michal Giermasinski <[email-masked]>
> *To:* Mosiuoa Tsietsi <[email-masked]>
> *Cc:* P2PSIP Mailing List <[email-masked]>
> *Sent:* Thursday, September 27, 2007 3:55 AM
> *Subject:* Re: [P2PSIP] A DHT question on peers running out of storage
>
> Hello Mosiuia, Jiang,
>
> I can see a potential problem here. When for storing some data in a 
> peer that has not enough place to store it you opt to send SIP 480 or 
> 486. Then data can be stored in the relevant peer with key neer the 
> chosen one. For sure this will work. But there will be a problem when 
> peer C would like to read these data. He will try to retrieve some 
> information according to the known key for DHT. But when reaching the 
> node that was supposed to store information this will fail. 3xx
message (redirection) will be sent.
>
> THis will work but we need to remember that this will not be optimal I

> guess.
>
> kind regards
> Michal
>
>
>
> 2007/9/26, Mosiuoa Tsietsi <[email-masked]>:
> >
> > Hi again,
> >
> > True, it's not the aim of P2P SIP to engineer DHT algorithms, but to

> > reuse what is there and hopefully provide generic interfaces to all 
> > things DHT (or all things P2P for that matter).  But I am hoping 
> > that pressure for such features will stimulate work in the area to 
> > provide such tweaks in the algorithms.  Much like you said Jiang, 
> > until such a time, the P2P node probably needs to be intelligent 
> > enough to at the higher level to avoid irregularities in the DHT.
> >
> > In the case of P2P over SIP, a node would probably want to send out 
> > something like a 480 Temp Unavailable or 486 Busy Here, and indicate

> > to the requestor to try some other node closer to the key until one 
> > such node is found. I'm guessing if there is no proper candidate 
> > found (though I imagine it is quite unlikely that such a situation 
> > may arise), the node is not allowed to register, until some free
space is found in the DHT.
> >
> > More or less the same for SIP over P2P, where the associated 
> > protocols employed for the put operation would fail, and the node 
> > would not be allowed entry until later.
> >
> > That said, the stuff I have been working on explores the possibility

> > of creating a new niche market for application developers who 
> > develop plugin wrapper objects for currently existing DHT 
> > implementations which implement a generic interface.  It does 
> > require a rather detailed understanding of the inner working of the 
> > DHT itself.  I'm hoping that other work in the area will put such 
> > kind of pressure so that more people start work in interventions in
DHTs for specific use in applications such as P2P SIP.
> >
> > Mos
> >
> > On 9/26/07, JiangXingFeng <[email-masked] > wrote:
> > >
> > > Hi all,
> > >
> > > >I agree that implementing this facility at a layer above the DHT
> > > logic is a
> > > >possibility. But I also think it can be achieved innately within 
> > > >the
> > > DHT
> > > algorithms >without breaking the mapping structure. Much in the 
> > > same way that proximity >metrics are incorporated into DHT 
> > > algorithms (for example to choose the "best >neighbor") perhaps 
> > > the same kind of logic can be used to choose the "best storer" of 
> > > >data. When the DHT is performing maintenance tasks, as it 
> > > optimises routing tables >and such, it can also take into
> > >
> > > consideration some storage metrics as well.
> > >
> > > Yes, if the DHT algorithm could provide the storage property like 
> > > what you've just described, I think it would be the best solution 
> > > to the issue of storage shortage of the peer.  P2PSIP peer 
> > > protocol does not intend to
> > >
> > > develop new DHT algorithms. What it really does is to accommodate 
> > > different DHT algorithms and make sure the message format could be

> > > extensible enough to convey the semantics of the each DHT 
> > > algorithm. So if the DHT algorithm does not solve the shortage of 
> > > the peer's storage, the better choice to this issue is to solve it

> > > on the upper layer application above.
> > >
> > > Comments?
> > >
> > > Mos
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >
> >
>  ------------------------------
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www1.ietf.org/pipermail/p2psip/attachments/20070927/be1f605d/atta
chment-0001.html

------------------------------

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

End of P2PSIP Digest, Vol 9, Issue 25
*************************************

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 9 Oct 2007 08:44:07 -0400

> http://www.ietf.org/internet-drafts/draft-matthews-p2psip-hip- 

We are working on an update to it.
The hip-hop-00 draft was just a high-level design sketch, and we are now
working out the details.

- Philip