Subject: [p2p-sip] p2p-sip Digest, Vol 8, Issue 61

From: kyara543 at yahoo.com (Kyara Yamamoto)
Date: Thu, 30 Mar 2006 16:36:24 -0800 (PST)

Can you dictate details about *down-to-earth* approach? 

We, scientists, leads, researchers  and professors are mainly for protocol design. Engineers realize protocols. We do not endorse realization. Realization takes time/resources and those with only academic value like SOSIMPLE or VOCAL is of tiny use to industry and consumers.

--Kyara

p2p-sip-request at cs.columbia.edu wrote:maybe a down-to-earth approach can help uncover problems in current p2p-sip
direction.

egs,

* do sip retransmission scheme and backoff timers fit well in p2p arena?
(some p2p msgs need no retransmission)
* what if a sip/udp packet exceeds MTU with appended p2p info (eg,
finger/k-bucket entries)?
* can p2p-sip keep incremental paces (and "religion") after strong security
and distributed databases are added to the overlayS in later phases?
* even if it imaginably can, will it be imaginably efficient and
competitive? (h323 and Jabber fans criticize protocol efficiency of sip even
with sigcomp)
* autonomous certificate management...etc

me feel the p2p-sip topic definitely not SOSIMPLE...

peter
----- Original Message -----
From: Mike Robinson
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Sent: Wednesday, March 29, 2006 9:18 PM
Subject: Re: [p2p-sip] Some comments on Use-cases document

Eunsoo wrote

>A P2P-based VoIP service provider has more subscribers than any other
> VoIP providers currently.

>Other commercial developments related to P2P SIP are being released via >
news media.

What does it really prove?  Let us see.

Unfortunately, you are  equating Skype  VoIP over  P2P with your version of
p2psip. "P2P VOIP (as in skype) works" is neither a proof nor a validation
of your p2p sip design since skype is not based on p2p sip. Besides,   it
is not a pure p2p solution in a strict sense. Skype documentation also lists
a number of optimizations that go far beyond signaling a session to get the
better voice quality. Please see their site for more details.

Actually, without having some support from an infrastructure provider (or
always connected nodes in the public domain) it may not be even possible to
run a pure p2p voip system beyond your organization. You have issues! of NAT
traversal, authentication and  certification management  that cannot be
simply washed away. Both Krishna Sankar and Karst raised a number of
technical issues.

May be what IETF needs a VOIP over P2P forum, rather than P2P SIP group.
In the p2p sip, all you are using p2p overlay is for resolving URI into end
point
IP addresses.  That can be done in many ways, and SIP can be used in the
unmodified way as it is. It may be possible that you don't even need to
tinker much with SIP (johnson's draft discusses one such possibility).

In addition, using  p2p overlay to resolve URIs does not solve  voice
quality issues, and I think Krishna Sankar articulated those issues very
well. So, if you believe in skype, that means that you need voip over p2p
group that looks into broader issues than the proposed p2p sip group.

--mike

Eunsoo Shim  wrote:
Mike Robinson wrote:

>
> Radhika:
>
> You agree that there are many problems that are not resolved yet, and
> no solution is available. That means more research needs to be done.
> Research belongs in the labs, Universities or in IRTF.
>
The P2P technologies are continusouly evolving and still various issues
remain open. There was a good presentation about DHT in the technical
plenary of IETF65, which pointed out many security issues of DHTs.
However, the conclusion of the presentation was not "don't use DHT" but
rather "use DHT with caution" to be simplified in my understanding.
A P2P-based VoIP service provider has more subscribers than any other
VoIP providers currently. Other commercial developments related to P2P
SIP are being released via news media. I think this is a quite strong
signal calling for P2! P SIP standardization efforts. The number of people
who have been showing interest in P2P SIP last several IETF meetings is
another signal, I think.

Novertheless, in general, I guess it is a quite subjective matter
whether a particular technology is ready for standardization or its
standardization is worth the effort. But I guess you can agree that it
is not a good idea waiting for all the problems to be solved before
standardization of anything.
Many protocols or technologies have been evolving even after the first
version of their standards. It does not mean standardization of those
protocols was a mistake or worthless.
Considering all the time we spent so far on discussions about various
apsects of P2P SIP, I think we have passed the stage to say "there are
lots of problems unsolved". Would it be too much if I ask for more
concrete discussions like what tools we can develop, what use case can
be supported in which ma! nner, and what is the difficulty for a certain
use case?

> It is not clear how you can change a DHT and still be compatible since
> SIP messages and headers fields are so much dependent on the type of
> underlying DHT used.

I thought you attended the P2P SIP ad-hoc meeting in Dallas but maybe I
was confused.
What you are describing above is based on a certain approach. Please
check the presentation about a P2P SIP architecture made during the
ad-hoc meeting in Dallas. The presentation is available in the IETF65
agenda and presentation page. You can find a different approach that
enables a modular design in which the underlying DHT or an overlay
algorithm can be changed without affecting the SIP messages.

> The data maintained by each DHT is different and so are node insertion
> and removal procedures. I believe the security issues of each DHT
> types would also be different, so when someone says tha! t they can
> replace DHT later on, they are just being too simplistic.
>
> Do you really want to create OSPF versus IS-IS kind of two
> incompatible solutions?
>
I think what Radhika meant was that different P2P SIP domains could use
different DHTs. OSPF and IS-IS won't be together in the same domain but
each can be used in different domains. Same approach for P2P SIP. Again
please check the P2P SIP architecture presentation in the ad-hoc meeting.

I respect your concern regarding P2P SIP standardization. Such concern
was expressed back in the first P2P SIP ad-hoc meeting in March last
year. We have come a long way since then to have a proposed charter and
the BOF in Dallas.

I hope we move forward.
Thanks.

Eunsoo
ps)I think David made really good points.

>
> */"Roy, Radhika R." /* wrote:
>
> I agree with David.
> It is also NOT harm! to link! age a particular design with a
> particular DHT, if this is the good choice for a given time.
> However, other proposals are also welcome. It is an open to all of us.
> Standardizations are always done throughout the world if there is
> a consensus to go for something that is good. With respect
> P2P-SIP, there are a lot of things to be solved. However, if
> something provides immediate value, as David and many others of
> this list have opined, what is the problem for standardization? A
> better standard in the future can always supersede an inferior
> standard of the past.
> Best regards,
> Radhika
> ------------------------------------------------------------------------
> *From:* p2p-sip-bounces at cs.columbia.edu
> [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *David Barrett
> *Sent:* Monday, March 27, 2006 2:40 PM> *To:* 'Mike Robinson';
henry at pulver.com; 'Karst Bjorgson'; 'Kyara
> Yamamoto'; 'Peter Pan'
> *Cc:* p2p-sip at cs.columbia.edu
> *Subject:* Re: [p2p-sip] Some comments on Use-cases document
> I guess one view is the IETF should forever be relegated to the j!
> anitorial role of cleaning up after the party????????s over. But I
> believe the IETF can participate in and even promote the party
> through standardization. I????????d like the IETF to do more than
> simply formalize de facto standards, but actually create the
> standards that attract the party.
> In the case of P2P-SIP, I entirely agree there are multiple,
> valid, proven ways to solve each of these problems ???????? none of
> which is the clear victor. And I also agree there are outstanding
> issues that have no proven solutions.
> If we pick amongst the best practices today, and skip the problems
> to which we have no clear solution, I personally believe that????????ll
> give us the most immediate value, while paving the road for future
> improvements. I don????????t believe we????????ll ever meet any higher
> standard to get started than has already been met.
> -david
> ------------------------------------------------------------------------
> *From:* p2p-sip-bounces at cs.columbia.edu
> [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *Mike Robinson
> *Sent:* Monday, March 27, 2006 10:32 AM
> *To:* henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter
> Pan'
> *Cc:* p2p-sip at cs.columbia.edu
> *Subject:* Re: [p2p-sip] Some comments on Use-cases document
> Henry:
> Do I need to tell that 48! 00 P2P google references have nothing
> to do with P2P SIP?
> Please let us not obfuscate the issues. You ! know, as well as,
> anyone sincere about the value of standards, that the pre-mature
> standardization leads to bad design as well as failure of the
> standards. As I mentioned there is no compelling use case
> presented yet that says we need to "standardize" p2p sip now
> without even bothering to get output from P2P IRTF group which is
> looking into core issues of P2P research.
> Many would say that we first need an IETF standard for P2P file
> sharing before we want to use "P2P" to design P2P SIP. We need
> more research on P2P SIP before we standardize any particular
> "conspiracy" (I use conspiracy in the sense of Karst definition of
> linking design with a particular DHT)
> -mike
> V! OIP and SIP Trainer and Consultant
>
> */Henry Sinnreich /* wrote:
>
> Mike Robinson writes:
>>How many! research ! or analytical papers have been published
> in this area?
> I have found by Googling a reference listing 4,800 papers on
> P2P. Hopefully, this enough to get us started. J
> Henry
>
> rates.
>
>
> ------------------------------------------------------------------------
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great
> rates starting at 1??????/min.
>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1??/min.

From: Eunsoo Shim <eunsoo at research.panasonic.com>
CC: p2p-sip at cs.columbia.edu
To: Mike Robinson <mike_robnson at yahoo.com>
Date: Thu, 30 Mar 2006 16:28:56 -0500
Subject: Re: [p2p-sip] Some comments on Use-cases document

 Mike Robinson wrote:

>
> Eunsoo wrote
>
> >A P2P-based VoIP service provider has more subscribers than any other
> > VoIP providers currently.
>
> >Other commercial developments related to P2P SIP are being released 
> via > news media.
>
> What does it really prove? Let us see.
>
> Unfortunately, you are equating Skype VoIP over P2P with your version 
> of p2psip. "P2P VOIP (as in skype) works" is neither a proof nor a 
> validation of your p2p sip design since skype is not based on p2p sip. 
> Besides, it is not a pure p2p solution in a strict sense.

I guess you mean something without any kind of central entity by 'pure 
p2p solution in a strict sense'. If you review discussions in the past 
P2P SIP ad-hoc meetings and in the mailing list, you may find out that 
the group is quite open for assuming some limited central entities, in 
particular, for authentication. As the proposed charter suggests, many 
people think a distributed identity management is a hard problem and the 
group should not try to standardize a protocol for that w.r.t. P2P SIP.

> Skype documentation also lists a number of optimizations that go far 
> beyond signaling a session to get the better voice quality. Please see 
> their site for more details.
>
> Actually, without having some support from an infrastructure provider 
> (or always connected nodes in the public domain) it may not be even 
> possible to run a pure p2p voip system beyond your organization. You 
> have issues! o! f NAT traversal, authentication and certification 
> management that cannot be simply washed away. Both Krishna Sankar and 
> Karst raised a number of technical issues.

All those issues have been raised and discussed in the group from the 
beginning.

>
> May be what IETF needs a VOIP over P2P forum, rather than P2P SIP group.

I guess you mean a group to design a complete P2P VoIP system by 'a VoIP 
over P2P forum'. You may notice that IETF WGs do not design a complete 
system but design protocols that are components of systems or tools. It 
is (should be) applied to the P2P SIP group, too.

> In the p2p sip, all you are using p2p overlay is for resolving URI 
> into end point
> IP addresses.

You are close. Basically the P2P overlay provides a resource location 
service for SIP. The resource could be UA (or user), TURN server, and so 
on.

> That can be done in many ways, and SIP can be used in the unmodified 
> way as it is.

That's the approach a number of people proposed.

> It may be possible that you don't even need to tinker much with SIP 
> (johnson's draft discusses one such possibility).
>
> In addition, using p2p overlay to resolve URIs does not solve voice 
> quality issues,

Right. Neither SIP or P2P overlay protocol will solve voice quality 
issues. The group is not aimed to address voice quality issues.
For example, for voice quality, codec selection is important. The SDP 
can be used to notify the type of the codec. But you got to develop an 
algorithm to select a codec, which is not what an IETF WG does 
typically. You may need a better voice codec. It is not dealt with in 
the IETF, either. Please don't expect an IETF WG will address/do all 
those things.
This group is not supposed to address all kind of issues related to 
SIP-based P2P real-time media applications. The group should develop a 
few tools/components by which people can build a system.

> and I think Krishna Sankar articulated those issues very well. So, if 
> you believe in skype, that means that you need voip over p2p group 
> that looks into broader issues than the proposed p2p sip group.
>
Again, I understand there are broader issues than what is covered by the 
proposed charter. Actually that is the purpose of the charter --- 
narrowing down and defining a limited scope/deliverables.

Thanks.

Eunsoo

>
>
>
>
> */Eunsoo Shim /* wrote:
>
>     Mike Robinson wrote:
>
>     >
>     > Radhika:
>     >
>     > You agree that there are many problems that are not resolved
>     yet, and
>     > no solution is available. That means more research needs to be
>     done.
>     > Research belongs in the labs, Universities or in IRTF.
>     >
>     The P2P technologies are continusouly evolving and still various
>     issues
>     remain open. There was a good presentation about DHT in the technical
>     plenary of IETF65, which pointed out many security issues of DHTs.
>     However, the conclusion of the presentation was not "don't use
>     DHT" but
>     rather "use DHT with caution" to be simplified in my understanding.
>     A P2P-based VoIP service provider has more subscribers than any other
>     VoIP providers currently. Other commercial developments related to
>     P2P
>     SIP are being released via news media. I think this is a quite strong
>     signal calling for P2! P ! SIP standardization efforts. The number
>     of people
>     who have been showing interest in P2P SIP last several IETF
>     meetings is
>     another signal, I think.
>
>     Novertheless, in general, I guess it is a quite subjective matter
>     whether a particular technology is ready for standardization or its
>     standardization is worth the effort. But I guess you can agree
>     that it
>     is not a good idea waiting for all the problems to be solved before
>     standardization of anything.
>     Many protocols or technologies have been evolving even after the
>     first
>     version of their standards. It does not mean standardization of those
>     protocols was a mistake or worthless.
>     Considering all the time we spent so far on discussions about various
>     apsects of P2P SIP, I think we have passed the stage to say "there
>     are
>     lots of problems unsolved". Would it be too much if I ask for more
>     concrete discussions like what tools we can develop, what use case
>     can
>     be supported in which ma! nn! er, and what is the difficulty for a
>     certain
>     use case?
>
>     > It is not clear how you can change a DHT and still be compatible
>     since
>     > SIP messages and headers fields are so much dependent on the
>     type of
>     > underlying DHT used.
>
>     I thought you attended the P2P SIP ad-hoc meeting in Dallas but
>     maybe I
>     was confused.
>     What you are describing above is based on a certain approach. Please
>     check the presentation about a P2P SIP architecture made during the
>     ad-hoc meeting in Dallas. The presentation is available in the IETF65
>     agenda and presentation page. You can find a different approach that
>     enables a modular design in which the underlying DHT or an overlay
>     algorithm can be changed without affecting the SIP messages.
>
>     > The data maintained by each DHT is different and so are node
>     insertion
>     > and removal procedures. I believe the security issues of each DHT
>     > types would also be different, so when someone says tha! t !
>     they can
>     > replace DHT later on, they are just being too simplistic.
>     >
>     > Do you really want to create OSPF versus IS-IS kind of two
>     > incompatible solutions?
>     >
>     I think what Radhika meant was that different P2P SIP domains
>     could use
>     different DHTs. OSPF and IS-IS won't be together in the same
>     domain but
>     each can be used in different domains. Same approach for P2P SIP.
>     Again
>     please check the P2P SIP architecture presentation in the ad-hoc
>     meeting.
>
>     I respect your concern regarding P2P SIP standardization. Such
>     concern
>     was expressed back in the first P2P SIP ad-hoc meeting in March last
>     year. We have come a long way since then to have a proposed
>     charter and
>     the BOF in Dallas.
>
>     I hope we move forward.
>     Thanks.
>
>     Eunsoo
>     ps)I think David made really good points.
>
>     >
>     > */"Roy, Radhika R." /* wrote:
>     >
>     > I agree with David.
>     > It is also NOT harm! t! o link! age a particular design with a
>     > particular DHT, if this is the good choice for a given time.
>     > However, other proposals are also welcome. It is an open to all
>     of us.
>     > Standardizations are always done throughout the world if there is
>     > a consensus to go for something that is good. With respect
>     > P2P-SIP, there are a lot of things to be solved. However, if
>     > something provides immediate value, as David and many others of
>     > this list have opined, what is the problem for standardization? A
>     > better standard in the future can always supersede an inferior
>     > standard of the past.
>     > Best regards,
>     > Radhika
>     >
>     ------------------------------------------------------------------------
>     > *From:* p2p-sip-bounces at cs.columbia.edu
>     > [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *David
>     Barrett
>     > *Sent:* Monday, March 27, 2006 2:40 PM> *To:* 'Mike Robinson';
>     henry at pulver.com; 'Karst Bjorgson'; 'Kyara
>     > Yamamoto'; 'Peter Pan'
>     > *Cc:* p2p-sip at cs.columbia.edu
>     > *Subject:* Re: [p2p-sip] Some comments on Use-cases document
>     > I guess one view is the IETF should forever be relegated to the j!
>     > anitorial role of cleaning up after the party???s over. But I
>     > believe the IETF can participate in and even promote the party
>     > through standardization. I???d like the IETF to do more than
>     > simply formalize de facto standards, but actually create the
>     > standards that attract the party.
>     > In the case of P2P-SIP, I entirely agree there are multiple,
>     > valid, proven ways to solve each of these problems ??? none of
>     > which is the clear victor. And I also agree there are outstanding
>     > issues that have no proven solutions.
>     > If we pick amongst the best practices today, and skip the problems
>     > to which we have no clear solution, I personally believe that???ll
>     > give us the most immediate value, while paving the road for future
>     > improvements. I don???t believe we???ll ever meet any higher
>     > standard to get started than has already been met.
>     > -david
>     >
>     ------------------------------------------------------------------------
>     > *From:* p2p-sip-bounces at cs.columbia.edu
>     > [mailto:p2p-sip-bounces at cs.columbia.edu] *On Behalf Of *Mike
>     Robinson
>     > *Sent:* Monday, March 27, 2006 10:32 AM
>     > *To:* henry at pulver.com; 'Karst Bjorgson'; 'Kyara Yamamoto'; 'Peter
>     > Pan'
>     > *Cc:* p2p-sip at cs.columbia.edu
>     > *Subject:* Re: [p2p-sip] Some comments on Use-cases document
>     > Henry:
>     > Do I need to tell that 48! 00 P2P google references have nothing
>     > to do with P2P SIP?
>     > Please let us not obfuscate the issues. You ! kn! ow, as well as,
>     > anyone sincere about the value of standards, that the pre-mature
>     > standardization leads to bad design as well as failure of the
>     > standards. As I mentioned there is no compelling use case
>     > presented yet that says we need to "standardize" p2p sip now
>     > without even bothering to get output from P2P IRTF group which is
>     > looking into core issues of P2P research.
>     > Many would say that we first need an IETF standard for P2P file
>     > sharing before we want to use "P2P" to design P2P SIP. We need
>     > more research on P2P SIP before we standardize any particular
>     > "conspiracy" (I use conspiracy in the sense of Karst definition of
>     > linking design with a particular DHT)
>     > -mike
>     > V! OIP and SIP Trainer and Consultant
>     >
>     > */Henry Sinnreich /* wrote:
>     >
>     > Mike Robinson writes:
>     >>How many! r! esearch ! or analytical papers have been published
>     > in this area?
>     > I have found by Googling a reference listing 4,800 papers on
>     > P2P. Hopefully, this enough to get us started. J
>     > Henry
>     >
>     > rates.
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.
>     Great
>     > rates starting at 1???/min.
>     >
>     >
>     >
>     >
>     >
>     >------------------------------------------------------------------------
>     >
>     >_______________________________________________
>     >p2p-sip mailing list
>     >p2p-sip at cs.columbia.edu
>     >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>     >
>     >
>
>
> ------------------------------------------------------------------------
> Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great 
> rates starting at 1?/min. 
> 

From: Eunsoo Shim <eunsoo at research.panasonic.com>
CC: p2p-sip at cs.columbia.edu
To: "Krishna Sankar (ksankar)" <ksankar at cisco.com>
Date: Thu, 30 Mar 2006 16:38:40 -0500
Subject: Re: [p2p-sip] Questions on #5 "A P2P SIP Arch - 2 layer approach".

 Krishna Sankar (ksankar) wrote:

>Folks,
>
> Have some quick questions on slide #5 "A P2P SIP Arch - 2 layer
>approach". I assume:
>
> a) This is could be a network topology, definitely not a
>logical topology.
> b) ONs & SNs are all SIP end-points and will be hashed as
>per Chord algorithm.
>  
>
ON and SN are NOT SIP entities.
ONs do not participate in DHT.

> c) So even though there could be a visibility and
>reachability association between specific SNs and ONs, the P2P substrate
>will not reflect this, as the hash could place them in different areas
>in the ring. In fact, if the hash didn't, it will degenerate to a
>routing table (not that that is bad, but that is not what we want to
>achieve at a macro level)
>  
>
ONs are not in the (Chord) ring.

> d) Hopefully this diagram is not overloaded with NAT
>traversal as well. In that case, the SN will represent the ONs which
>hang off of it. In this case the hashing will happen on the ON name but
>the IP address will be that of the associated SN. The SN knows how to
>get to the Ones it represents.
>  
>
The diagram is not overloaded with NAT traversal.

> e) Extending a) further, the Chord ring representation of
>this diagram will be very different.
>  
>
Please see the answers in the above.

Thanks.

Eunsoo

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

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060330/daa9d819/attachment-0001.html