Subject: Re: [P2PSIP] implementation must *lead* standardization

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 09:36:50 +0200

This sounds great and in fact you need nothing from the P2PSIP group (or 
any other group) to immediately start with the suggested approach.
Good luck and hope that the group in a couple of years indeed values 
your solution.

Ciao
Hannes

David Barrett wrote:
> Personally, I'd go further and suggest we need somebody willing to not only
> build our Mosiac, we need someone willing to do it even though the result
> will more than likely be rejected by this group for years before we finally
> accept it.
>
>  
>
> We need somebody who recognizes that the "customer" for P2PSIP isn't the
> IETF, and it's not the people on this list.  The customer is the user who
> actually chooses it over competing alternatives, be that alternative Skype
> or AT&T or IM or simply not talking at all.
>
>  
>
> So we need somebody who will take all the very excellent ideas discussed on
> this list, boil them down to the tiny subset that actually matters, build
> something that actually works for real users, and then focus on getting them
> to adopt it - despite our howls of incredulity that it ignores 80% of our
> suggestions and only handles 20% of our use cases (the 20% that matter).
>
>  
>
> And then later, once he's succeeded in getting users to adopt his protocol
> (which might or might not bear any similarity to what we've discussed in our
> drafts), then he can come back here and tell us what P2P2SIP actually *is*
> (and not merely what we'd like it to be), and we can get started refining it
> to P2PSIP 1.1, 2.0, and beyond.
>
>  
>
> That's how all the other great protocols came about, so far as I can tell.
> Indeed, you might even say that's the standard technique for developing
> great protocols.  Who are we to deviate from standards?
>
>  
>
> -david
>
>  
>
>   _____  
>
> From: Michael Slavitch [mailto:[email-masked]] 
> Sent: Sunday, September 23, 2007 1:20 PM
> To: Hannes Tschofenig
> Cc: David Barrett; Henry Sinnreich; P2PSIP Mailing List
> Subject: Re: [P2PSIP] implementation must *lead* standardization
>
>  
>
> We have  Bamboo/OpenDHT,  we have ICE* for NAT traversal.  What we don't
> need now is any more deliberation without some form of implementation. 
> What we need now is our Mosaic.   That will tell us where we are barking up
> the wrong tree.  P2PSIP will then respond to real shortcomings getting in
> the way of real problems the same way HTTP evolved.   Telnet and email and
> even TCP evolved  the same way back in the stone age.
>
>  
> Given that:
>
>  
> 1]  Is there someone on this list capable of applying for a grant in the
> same way UIUC applied for a grant for Mosaic?
>
> 2]  If so, please do so, and try to build a Skype equivalent with
> Bamboo/OpenDHT/ICE/SIP.  I can offer references,  as  can others.
>
> 3]  Don't worry about it being perfect, let it be open source and based on
> protocol willing to be open to change and adapt to IETF standardization for
> the lower bits.  Like the W3 the higher bits may go somewhere else for
> standardization.
>
> 4]  Don't even think about writing an internet-draft .
>
> 5] Make sure it doesn't need servers and only a bootstrap.  Thanks.
>
> I could try the equivalent of this with VC's, but like the Boston's VC's's
> that laughed at the Facebook lads my locals will likely laugh too.    
>
>
> Regards
>
> Michael
>
>  
>
>  
>
> Objectworld, The IT Telephony Company TM
>
> 308 Legget Drive, Ottawa, Ontario K2K 1Y6
>
> Phone: +1 (613) 599-9698, x. 22 | Fax: +1 (613) 599-7457
>
> http://www.objectworld.com
>
>  
>
>  
>
>  
>
>  
>
> On 9/23/07, Hannes Tschofenig <[email-masked]> wrote:
>
> Hi David,
>
>   
>>> All of the proposed protocols would fail the "widely deployed" criteria.
>>>
>>>       
>> Er, none of HTTP, SSH, DNS, FTP, IRC, POP, SMTP are widely deployed?
>>     
> Uh...
>   
>>     
> No. I tried to figure out what the relevance of Henry's post with
> respect to this group is.
> Which protocols discussed in this group are widely deployed?
>
> It is nice to have some high-level discussions but there should at the 
> end be some conclusion. I am missing the conclusion for this group.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]  <mailto:[email-masked]> 
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>
>
>   

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 24 Sep 2007 08:53:43 -0700

Actually I am sure we need David Barrett very much in the P2PSIP WG and
hope David can participate.

Neither Hannes nor I can speak for whole WG, but just for balance...

Henry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 9:37 AM
To: David Barrett
Cc: 'Michael Slavitch'; Henry Sinnreich; 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] implementation must *lead* standardization

Ciao
Hannes

---

From: "Michael Slavitch" <[email-masked]>
Date: Mon, 24 Sep 2007 16:52:08 -0400

Stealing from RFC2026:

In general, an Internet Standard is a specification that is stable and
well-understood, is technically competent, has multiple,  independent, and
interoperable implementations with substantial operational experience, enjoys
significant public support, and is recognizably useful in some or all parts
of the Internet.

Given that, the opinions of the likes of David and others in the real world
are to be courted and encouraged and implementations are to be assisted as
they are a mandatory part of the standards process, not brushed away rudely
as an annoyance.

Without the rigor of implementation and wide use there is no standard, only
talk and drafts.  This is why the best standards tend to always be
standardized definitions of shared accepted implementations, not the other
way around.

---

From: "Alex Gakuru" <[email-masked]>
Date: Tue, 25 Sep 2007 00:08:05 +0300

This really teaches me a deep lesson at "rough consensus" building.

On 9/24/07, Michael Slavitch <[email-masked]> wrote:
> interoperable implementations with substantial operational experience,
> enjoys significant public support, and is recognizably useful in some or all
> parts of the Internet.
>
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 23:23:15 +0200

I guess we should conclude this discussion at the point where we have 
agreement: "Creating implementations while you write specifications is a 
Good Thing (tm)".

I worked on a couple of protocols and we also produced implementations. 
The implementation experience has always been helpful for us. In fact, 
most working groups produce implementations while they work on their specs.

Even in this group implementation projects are in progress for some of 
the proposals. Great!

I guess the disagreement just starts at details on when and how 
implementations can be turned into real deployment.

Ciao
Hannes

---

From: "Peter Pan" <[email-masked]>
Date: Mon, 24 Sep 2007 14:33:19 -0700

me too.

after the lesson i smile (not laugh) ...

----- Original Message -----
From: "Alex Gakuru" <[email-masked]>
To: "Michael Slavitch" <[email-masked]>
Cc: "Henry Sinnreich" <[email-masked]>; "P2PSIP Mailing List"
<[email-masked]>
Sent: Monday, September 24, 2007 2:08 PM
Subject: Re: [P2PSIP] implementation must *lead* standardization

---

From: "Peter Pan" <[email-masked]>
Date: Mon, 24 Sep 2007 14:41:12 -0700

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?

----- Original Message -----
From: "Hannes Tschofenig" <[email-masked]>
To: "Michael Slavitch" <[email-masked]>
Cc: "Henry Sinnreich" <[email-masked]>; "P2PSIP Mailing List"
<[email-masked]>
Sent: Monday, September 24, 2007 2:23 PM
Subject: Re: [P2PSIP] implementation must *lead* standardization

> > interoperable implementations with substantial operational experience,
enjoys

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 24 Sep 2007 14:44:32 -0700

RFC 2026 is a welcome reminder. Since Hannes has asked a fair question:

> Which proposal do you think is far enough regarding their
implementation work?

The answer is:

1.	Bamboo as the default for the DHT because of its unparalleled
maturity and system design, test reports, application on top, etc.
2.	P2PP for the SIP part, and
3.	TBD for NAT traversal: This is the missing item, since there are
no deployment statistics for STUN/TURN/ICE and we don't know how a DHT
will work where most of the peers are behind NAT in various scenarios.
This part must be proven with deployment statistics and not by concept
papers that without meeting RFC 2026 are only a distraction IMHO.

For all three items, please read the extract for RFC 2026 again and
remember it well.

In general, an Internet Standard is a specification that is stable and
well-understood, is technically competent, has multiple,  independent,
and interoperable implementations with substantial operational
experience, enjoys significant public support, and is recognizably
useful in some or all parts of the Internet.     

Thanks, Henry

________________________________

From: Michael Slavitch [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 10:52 PM
To: Henry Sinnreich
Cc: Hannes Tschofenig; David Barrett; P2PSIP Mailing List
Subject: Re: [P2PSIP] implementation must *lead* standardization

Stealing from RFC2026:

In general, an Internet Standard is a specification that is stable and
well-understood, is technically competent, has multiple,  independent,
and interoperable implementations with substantial operational
experience, enjoys significant public support, and is recognizably
useful in some or all parts of the Internet.     

Given that, the opinions of the likes of David and others in the real
world are to be courted and encouraged and implementations are to be
assisted as they are a mandatory part of the standards process, not
brushed away rudely as an annoyance. 

Without the rigor of implementation and wide use there is no standard,
only talk and drafts.  This is why the best standards tend to always be
standardized definitions of shared accepted implementations, not the
other way around.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Sep 2007 00:00:55 +0200

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:
>> most working groups produce implementations while they work on their
>>     
> specs.
>   
> and
>>> significant public support, and is recognizably useful in some or all
>>>       
> parts
>   
>>> of the Internet.
>>>
> world
>>> are to be courted and encouraged and implementations are to be assisted
>>>       
> as
>   
>>> they are a mandatory part of the standards process, not brushed away
>>>       
> rudely
>   
>>> as an annoyance.
>>>
> only
> other

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Sep 2007 21:41:47 -0400

> planning todo some implementation work) with regard to a proposal  

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

---

From: "Peter Pan" <[email-masked]>
Date: Mon, 24 Sep 2007 19:26:05 -0700

a quick question: shall p2psip be renamed to p2phip or hipsip :?

----- Original Message -----
From: "Philip Matthews" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Cc: "P2PSIP Mailing List" <[email-masked]>
Sent: Monday, September 24, 2007 6:41 PM
Subject: Re: [P2PSIP] Who is working on an implementation for a
P2PSIPproposal?

---

From: Philip Matthews <[email-masked]>
Date: Mon, 24 Sep 2007 22:34:23 -0400

> a quick question: shall p2psip be renamed to p2phip or hipsip :?

There is no WG agreement yet on using HIP for P2PSIP. At present, it  
is still an individual proposal. Even if it is accepted, I don't see  
that as a reason to rename the group.

- Philip

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 25 Sep 2007 09:03:00 +0200

> planning todo some implementation work) with regard to a proposal

For what it's worth, XPP-PCAN proposal is basically an implementation
report of the sipdht2 os project.  Right now the implementation has gone
quite further than the specs (funny, eh?), but we hope to be able to
update the drafts by the next meeting.

-- 
Ciao,
Enrico

---

From: Dean Willis <[email-masked]>
Date: Tue, 25 Sep 2007 03:44:24 -0500

We seem to expect that P2PSIP will create an explosion of new  
applications opportunities. Some have proposed that we just follow  
this expansion and document the version of P2PSIP that makes it  
happen, and declare that our standard.

I'm not sure I buy this.

What do we really expect a P2PSIP implementation to give us that we  
don't get well enough from legacy SIP, resulting in legacy SIP being  
incapable of delivering the same applications as P2PSIP?

Is it a massive user base? Cross-implementation compatibility? NAT  
traversal? Is it just that we expect P2PSIP to actually work well  
enough to use, and have found that legacy SIP doesn't?

I suspect it's none of the above. What I expect is that P2PSIP will  
have a marginally better operations overhead ratio than legacy SIP,  
which will give it a slight evolutionary advantage. I expect it to  
gradually displace legacy SIP, running in the same environmental  
niche, but better able to compete from an overhead basis.

SIP clearly scales well enough to have a large user base (look at  
Vonage, Gizmo, and so on). It clearly traverses NATs -- My mother  
uses a PAP2 (withGizmo) from behind a NAT box every day. Ok, most of  
the clients seem unsatisfactory -- I get much better audio quality  
with Skype on most every device I have, but that's an implementation  
issue, not the signaling protocol's fault, as far as I can tell. The  
overhead of legacy SIP is NOT killing us, save in the massive  
presence case (according to Avshalom's drafts), and we can clearly do  
SIMPLE without centralized servers without waiting for P2PSIP.

We should be doing those neat new applications on legacy SIP, where  
feasible. And if we find a "not feasible", then that gives us a  
restart of this conversation.

So why rush? Why not let the pendulum swing from implementation to  
specification and back as it winds the clockwork engine of slowly  
towards consensus? What is it we Absolutely Have to Get Done Now?

There might be something. If there is, let's identify and concentrate  
on meeting its specialized needs. If not, then we're just wasting  
time and energy arguing about fast versus slow evolution, because if  
there's one thing I believe, it is that there's no possibility of  
Intelligent Design happening in this sort of committee. We might as  
well wait for the camel to evolve gradually from the varieties of  
zebras, horses and donkeys we now see being offered up as templates.

Now that's all presuming that we don't have real, new, functional  
requirements that cannot be reasonably addressed via a more  
traditional solution. Do we have any of those?

--
Dean Willis

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Sep 2007 13:14:20 +0200

In the context of RFC 2026 it is not clear whether the paragraph is
referring to standards track documents or the end goal of the standards
track which is an Internet Standard. I believe it is the latter. That
means that you have "Proposed Standard" and "Draft Standard" to go
through before you get to "Internet Standard". In my belief, it is not
referring to the creation of an RFC. Very few IETF documents have yet
reached "Internet Standard" (we seem to have reached standard no. 67,
out of 5000 RFCs) - and RFC 2616 is not one of them. 
 
In fact no standards organisation, including the IETF, has a particular
success rate in creating documents that fulfil this criteria, in the
same way that no implementation group has the set of rules for creating
a successful product.
 
We can apply all sorts of rules we like, but I believe the one that has
no worse or no better chance of success is that we create documents that
we believe will be useful to the community at the time we create them.
At the end of the day the market decides and we stand a very low chance
of determining which will be the ones that get used.
 
Enough of the philosophy - either we believe there is something we can
validly publish or we don't.
 
regards
 
Keith

	From: Henry Sinnreich [mailto:[email-masked]] 
	Sent: Monday, September 24, 2007 10:45 PM
	To: Michael Slavitch; Henry Sinnreich
	Cc: P2PSIP Mailing List
	Subject: RE: [P2PSIP] implementation must *lead* standardization

	RFC 2026 is a welcome reminder. Since Hannes has asked a fair

implementation work?

	The answer is:

	1.	Bamboo as the default for the DHT because of its
unparalleled maturity and system design, test reports, application on
top, etc. 
	2.	P2PP for the SIP part, and 
	3.	TBD for NAT traversal: This is the missing item, since
there are no deployment statistics for STUN/TURN/ICE and we don't know
how a DHT will work where most of the peers are behind NAT in various
scenarios. This part must be proven with deployment statistics and not
by concept papers that without meeting RFC 2026 are only a distraction
IMHO. 

	For all three items, please read the extract for RFC 2026 again
and remember it well.

	In general, an Internet Standard is a specification that is
stable and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.     

	Thanks, Henry

	Stealing from RFC2026:
	
	In general, an Internet Standard is a specification that is
stable and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.     
	
	Given that, the opinions of the likes of David and others in the
real world are to be courted and encouraged and implementations are to
be assisted as they are a mandatory part of the standards process, not
brushed away rudely as an annoyance. 
	
	Without the rigor of implementation and wide use there is no
standard, only talk and drafts.  This is why the best standards tend to
always be standardized definitions of shared accepted implementations,
not the other way around.

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 25 Sep 2007 10:32:36 -0400

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

---

From: Adrian Georgescu <[email-masked]>
Date: Tue, 25 Sep 2007 16:44:04 +0200

AG Projects is also providing infrastructure solutions for self- 
organizing SIP Proxies by using P2PSIP concepts.

Adrian

---

From: "Mosiuoa Tsietsi" <[email-masked]>
Date: Tue, 25 Sep 2007 17:04:47 +0200

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

---

From: Ingmar Baumgart <[email-masked]>
Date: Wed, 26 Sep 2007 09:38:45 +0200

Hi,

we (research group of Martina Zitterbart, University of Karlsruhe) have
done a P2PSIP implementation based on our overlay framework OverSim
(http://www.oversim.org).

The actual P2PSIP part is a simple extension to the openser SIP proxy
which uses the external DHT and KBR services provided by OverSim via an
XML-RPC interface similiar to OpenDHT. Currently we have working overlay
implementions for Chord, Koorde, Broose, Pastry and Kademlia.

Although the focus of OverSim is on the simulation of overlay networks,
the protocol implementations can also be used in real networks. The
network wrapper currently generates messages based on OMNeT++'s message
structures, but we consider to extend this to P2PP or some similar approach.

The implementation was presented at IEEE P2P 2007
(http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf).

Regards,
  Ingmar

-- 
Dipl.-Inform. Ingmar Baumgart
Institut für Telematik, Universität Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone: +49 721 608 8281, Fax: +49 721 608 6789

---

From: Joakim Koskela <[email-masked]>
Date: Wed, 26 Sep 2007 10:36:01 +0300

Hi,

Here at HIIT me and a couple of collegues are working on a prototype for 
(near) infrastructureless SIP, aka p2psip, based partly on the design 
described in the p2psip-with-hip draft. Our proto is however only an adapter 
for normal SIP, used as a normal SIP proxy by existing SIP UAs instead of a 
complete all-in-one solution.

Also, the storage (for registrations and such) differes somewhat from the 
draft in that it isn't tied to a particular protocol or strictly based on a 
DHT or even P2P solution, but is pluggable (currently OpenDHT and 
multicasting is used). As multiple modules can (and should) be used 
simultaneously, in case there's a concensus on the peer protocol in this 
group I'd be interested to see if that could fit into a module as well 
(having the nodes form a DHT has always been in the roadmap..).

Connectivity and NAT traversal are dealt with by using the HIP protocol for 
establishing connections.

br ,j

-- 
Joakim Koskela
Helsinki Institute for Information Technology (HIIT)
email: [email-masked]
mobile: +358 50 5459786

---

From: "David Barrett" <[email-masked]>
Date: Wed, 26 Sep 2007 02:14:33 -0700

So there are lots of parallel implementations of P2PSIP.  Why don't we just
pick one and focus on that?  Update all the drafts to reflect precisely what
this one implementation *actually* does, and then go through a series of
update-drafts/debate-changes/implement-changes/repeat iterations.  Recognize
that the *actual* spec is what's implemented in the code.  Everything else
is just a proposal.

Maybe conduct all future P2PSIP WG meetings virtually using this tool?
Maybe just pick a time every week where we all agree to call someone else in
the group -- maybe even have a "random call" button for just this purpose --
for no other reason than to test the latest build?

Eat our own dogfood, and keep eating it until it starts to taste good.

I mean, if even we don't bother to use it, why should we expect anybody else
to?

-david

> standard,

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 26 Sep 2007 11:50:32 +0200

Hello,

On 26/09/2007, David Barrett <[email-masked]> wrote:
> this one implementation *actually* does

What about re-building the selected implementation considering all the drafts?

Could we make a public directory with all P2PSIP implementations and
then pick one with consensus?

> for no other reason than to test the latest build?

I think it's a good idea.

I also suggest to use a virtual area (e.g. IRC) open for discussion.

Thanks,
Victor Pascual

---

From: "Peter Pan" <[email-masked]>
Date: Wed, 26 Sep 2007 08:03:13 -0700

me really cannot find anything wrong with the theory of peaceful evolution.

the wg seems a tow between irrigated turtles and thursty hares.