Subject: [p2p-sip] Some comments on Use-cases document

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 30 Mar 2006 17:20:58 -0500

Inline [RRR]

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of Eunsoo Shim
Sent: Thu 3/30/2006 4:28 PM
To: Mike Robinson
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Some comments on Use-cases document

Mike Robinson wrote: 

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

[RRR] In addition what Eunsoo explained, the QoS issues for real-time
applications (e.g., audio, video) are being addressed in IETF NSIS WG in
addition what DiffServ and RSVP deal with.

[RRR] p2p-sip is not supposed to anything new what SIP is already is doing
for QoS (e.g., SIP signaling messages are being extended to invoke lower
layer QoS signaling messages at the time of the call setup). So, the
voice/video quality is a non-issue for p2p-sip.

Thanks. 

Eunsoo 

> 
> 
> 
> 
> */Eunsoo Shim <eunsoo at research.panasonic.com>/* 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
<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?EUR(tm)s over. But I 
>     > believe the IETF can participate in and even promote the party 
>     > through standardization. I?EUR(tm)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 ?EUR" 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?EUR(tm)ll 
>     > give us the most immediate value, while paving the road for future 
>     > improvements. I don?EUR(tm)t believe we?EUR(tm)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
<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
<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. 
>
<http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/ev
t=39666/*http://beta.messenger.yahoo.com
<http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/ev
t=39666/*http://beta.messenger.yahoo.com> > 

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