From don_miguel at chile.com Mon Oct 3 16:11:31 2005 From: don_miguel at chile.com (Miguel) Date: Mon Oct 3 16:14:25 2005 Subject: [p2p-sip] SPIT on p2p-SIP Networks Message-ID: <43419073.60502@chile.com> Hi, first, thank's to BR/Radhika to answer may last question. Well, I was reading how SPIT (Spam over Internet Telephony) could become a problem in SIP VoIP providers. This problem could be resulted with an array of SBC's, if they are enougth mature to that kind of functions. However, in p2p networks, it's preaty more dificult to solve the problem; in fact, I really don't know how it could be done, unlesss you control any node or supernode with a heavy aplication. Am I rigth? Regards Miguel Saravia From RoyR at saic-abingdon.com Mon Oct 3 16:36:42 2005 From: RoyR at saic-abingdon.com (Roy, Radhika (AEAD)) Date: Mon Oct 3 16:34:08 2005 Subject: [p2p-sip] SPIT on p2p-SIP Networks Message-ID: <2FE23D25B7292B489A217D1965CDA8660898D6@bh-exchange02.saic-abingdon.com> Hi, Miguel: P2P has got some problems as well. For example, it is somewhat like "push." As a result, how to avoid spam in P2P is an issue. However, to deal with spam is not unique in p2p. In general, spam is an issue for all. For example, as you have mentioned, heavy-application-based super-node can be one of the solutions for both p2p and non-p2p system. If we focus on the usefulness of the p2p system first, the associated problems can be looked into in the general context of the overall Internet problems such as security, spam, QOS, etc. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of Miguel Sent: Monday, October 03, 2005 4:12 PM To: p2p-sip@cs.columbia.edu Subject: [p2p-sip] SPIT on p2p-SIP Networks Hi, first, thanks to BR/Radhika to answer may last question. Well, I was reading how SPIT (Spam over Internet Telephony) could become a problem in SIP VoIP providers. This problem could be resulted with an array of SBC's, if they are enough mature to that kind of functions. However, in p2p networks, it's pretty more difficult to solve the problem; in fact, I really don't know how it could be done, unless you control any node or super-node with a heavy application. Am I right? Regards Miguel Saravia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051003/05727c9a/attachment.html From bryan at ethernot.org Wed Oct 5 10:37:16 2005 From: bryan at ethernot.org (David A. Bryan) Date: Wed Oct 5 10:38:30 2005 Subject: [p2p-sip] P2P SIP Ad-Hoc at IETF 64 Message-ID: <8b2769930510050737x72ec990dvd066765a2aa59fc3@mail.gmail.com> Just an FYI to everyone. I've been working with the SIPPING chairs, and Eyeball networks, which has offered to sponsor the room, and it appears that we are going to meet Friday, September 11, from either 1-6 or 12-5. This should give us a bit longer to discuss things than we had in Paris. Final details (and a post to SIPPING) will come after we work out the exact details -- will likely be off site, but walkable. Just wanted to let everyone know as soon as possible (sorry for the delay) so they could book appropriately. I'm working on a draft agenda. If you haven't already sent items you would like considered, please send them to me, and I'll try to get a list of the most commonly requested topics together in the next few days. Hope to see many of you there! David Bryan From bryan at ethernot.org Wed Oct 5 11:45:53 2005 From: bryan at ethernot.org (David A. Bryan) Date: Wed Oct 5 11:46:33 2005 Subject: [p2p-sip] Re: P2P SIP Ad-Hoc at IETF 64 In-Reply-To: <4343EAF6.2090106@ericsson.com> References: <20051005145525.580FA51C@mailgw1.ericsson.se> <4343EAF6.2090106@ericsson.com> Message-ID: <8b2769930510050845m563445f5x6c725e7213fd2eec@mail.gmail.com> Yep. Sorry...I'm so far behind on work I'm scheduling things last month :) David On 10/5/05, Gonzalo Camarillo wrote: > Henry, > > yes, the idea will be to use the last Friday of the IETF meeting. > > Cheers, > > Gonzalo > > Henry Sinnreich wrote: > > David, > > > > Did you mean Friday, November 11? > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On Behalf Of David > > A. Bryan > > Sent: Wednesday, October 05, 2005 9:37 AM > > To: P2P-SIP > > Cc: Cullen Jennings; Henning Schulzrinne; henry@pulver.com; Gonzalo > > Camarillo; Rohan Mahy; Dean Willis; Bruce Lowekamp > > Subject: P2P SIP Ad-Hoc at IETF 64 > > > > Just an FYI to everyone. I've been working with the SIPPING chairs, > > and Eyeball networks, which has offered to sponsor the room, and it > > appears that we are going to meet Friday, September 11, from either > > 1-6 or 12-5. This should give us a bit longer to discuss things than > > we had in Paris. Final details (and a post to SIPPING) will come after > > we work out the exact details -- will likely be off site, but > > walkable. Just wanted to let everyone know as soon as possible (sorry > > for the delay) so they could book appropriately. > > > > I'm working on a draft agenda. If you haven't already sent items you > > would like considered, please send them to me, and I'll try to get a > > list of the most commonly requested topics together in the next few > > days. > > > > Hope to see many of you there! > > > > David Bryan > > > > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > From matthews at nimcatnetworks.com Thu Oct 6 14:08:05 2005 From: matthews at nimcatnetworks.com (Philip Matthews) Date: Thu Oct 6 14:44:14 2005 Subject: [p2p-sip] Goals of Ad-hoc meeting at IETF 64 Message-ID: I think the main goal of this ad-hoc meeting should be trying to find points of commonality between people's systems and interests. In my opinion, there is no way we can get a working group going until we have something focused to work on. In Paris, we saw that there were some ideas in common -- it seems to me that the goal of this meeting should be to flesh those out and prioritize them. We should prepare a list of work items for a possible WG and to have a fairly good idea how we might achieve them. - Philip -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan Sent: October 5, 2005 10:37 To: P2P-SIP Cc: Rohan Mahy; henry@pulver.com; Gonzalo Camarillo; Bruce Lowekamp Subject: [p2p-sip] P2P SIP Ad-Hoc at IETF 64 Just an FYI to everyone. I've been working with the SIPPING chairs, and Eyeball networks, which has offered to sponsor the room, and it appears that we are going to meet Friday, September 11, from either 1-6 or 12-5. This should give us a bit longer to discuss things than we had in Paris. Final details (and a post to SIPPING) will come after we work out the exact details -- will likely be off site, but walkable. Just wanted to let everyone know as soon as possible (sorry for the delay) so they could book appropriately. I'm working on a draft agenda. If you haven't already sent items you would like considered, please send them to me, and I'll try to get a list of the most commonly requested topics together in the next few days. Hope to see many of you there! David Bryan _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From eunsoo at research.panasonic.com Thu Oct 6 15:39:32 2005 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu Oct 6 15:40:08 2005 Subject: [p2p-sip] Goals of Ad-hoc meeting at IETF 64 In-Reply-To: References: Message-ID: <43457D74.5090508@research.panasonic.com> I agree with Philip. To add my spin, I think we should focus on what we can and should do in a reasonable time frame rather than try to identify all the difficult problems related to P2P and P2P SIP or to cover all the advanced features we can imagine. Regards, Eunsoo Philip Matthews wrote: >I think the main goal of this ad-hoc meeting should be trying >to find points of commonality between people's systems and interests. > >In my opinion, there is no way we can get a working group going until >we have something focused to work on. In Paris, we saw that there >were some ideas in common -- it seems to me that the goal of this >meeting should be to flesh those out and prioritize them. We should >prepare a list of work items for a possible WG >and to have a fairly good idea how we might achieve them. > >- Philip > > >-----Original Message----- >From: p2p-sip-bounces@cs.columbia.edu >[mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan >Sent: October 5, 2005 10:37 >To: P2P-SIP >Cc: Rohan Mahy; henry@pulver.com; Gonzalo Camarillo; Bruce Lowekamp >Subject: [p2p-sip] P2P SIP Ad-Hoc at IETF 64 > >Just an FYI to everyone. I've been working with the SIPPING chairs, >and Eyeball networks, which has offered to sponsor the room, and it >appears that we are going to meet Friday, September 11, from either >1-6 or 12-5. This should give us a bit longer to discuss things than >we had in Paris. Final details (and a post to SIPPING) will come after >we work out the exact details -- will likely be off site, but >walkable. Just wanted to let everyone know as soon as possible (sorry >for the delay) so they could book appropriately. > >I'm working on a draft agenda. If you haven't already sent items you >would like considered, please send them to me, and I'll try to get a >list of the most commonly requested topics together in the next few >days. > >Hope to see many of you there! > >David Bryan > >_______________________________________________ >p2p-sip mailing list >p2p-sip@cs.columbia.edu >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > >_______________________________________________ >p2p-sip mailing list >p2p-sip@cs.columbia.edu >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > From matthews at nimcatnetworks.com Thu Oct 6 16:07:56 2005 From: matthews at nimcatnetworks.com (Philip Matthews) Date: Thu Oct 6 16:10:20 2005 Subject: [p2p-sip] Goals of Ad-hoc meeting at IETF 64 Message-ID: Eunsoo Shim wrote: > To add my spin, I think we should focus on what we can and should do in > a reasonable time frame rather than try to identify all the difficult > problems related to P2P and P2P SIP or to cover all the advanced > features we can imagine. I agree. - Philip From Gonzalo.Camarillo at ericsson.com Wed Oct 5 11:02:14 2005 From: Gonzalo.Camarillo at ericsson.com (Gonzalo Camarillo) Date: Sat Oct 8 09:51:24 2005 Subject: [p2p-sip] Re: P2P SIP Ad-Hoc at IETF 64 In-Reply-To: <20051005145525.580FA51C@mailgw1.ericsson.se> References: <20051005145525.580FA51C@mailgw1.ericsson.se> Message-ID: <4343EAF6.2090106@ericsson.com> Henry, yes, the idea will be to use the last Friday of the IETF meeting. Cheers, Gonzalo Henry Sinnreich wrote: > David, > > Did you mean Friday, November 11? > > Thanks, Henry > > > > -----Original Message----- > From: davidbryan@gmail.com [mailto:davidbryan@gmail.com] On Behalf Of David > A. Bryan > Sent: Wednesday, October 05, 2005 9:37 AM > To: P2P-SIP > Cc: Cullen Jennings; Henning Schulzrinne; henry@pulver.com; Gonzalo > Camarillo; Rohan Mahy; Dean Willis; Bruce Lowekamp > Subject: P2P SIP Ad-Hoc at IETF 64 > > Just an FYI to everyone. I've been working with the SIPPING chairs, > and Eyeball networks, which has offered to sponsor the room, and it > appears that we are going to meet Friday, September 11, from either > 1-6 or 12-5. This should give us a bit longer to discuss things than > we had in Paris. Final details (and a post to SIPPING) will come after > we work out the exact details -- will likely be off site, but > walkable. Just wanted to let everyone know as soon as possible (sorry > for the delay) so they could book appropriately. > > I'm working on a draft agenda. If you haven't already sent items you > would like considered, please send them to me, and I'll try to get a > list of the most commonly requested topics together in the next few > days. > > Hope to see many of you there! > > David Bryan > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo From mahesh.govind at samsung.com Mon Oct 10 21:31:40 2005 From: mahesh.govind at samsung.com (Mahesh Govind) Date: Mon Oct 10 21:33:01 2005 Subject: [p2p-sip] Links Message-ID: <002601c5ce03$87a0e720$fbcbd5a5@mahesh> HI , I thik, we can refer to the internet RG for p2p for related work . There they are having some good documents , which may help us . http://www.irtf.org/charter?gtype=rg &group=p2prg With regards Mahesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051011/803cea51/attachment.html From bryan at ethernot.org Mon Oct 17 17:13:08 2005 From: bryan at ethernot.org (David A. Bryan) Date: Mon Oct 17 17:14:08 2005 Subject: [p2p-sip] IETF-64 Vancouver P2P SIP Adhoc BOF Time/Location/Draft Agenda Message-ID: <8b2769930510171413j5cdb9647sd34e6e608f94f257@mail.gmail.com> Hello all, The folks at Eyeball who have agreed to sponsor a venue for the P2P SIP Ad-Hoc BOF have gotten things scheduled (thanks!), so I wanted to pass along this information, and a draft agenda. Comments welcome. P2P SIP Ad-Hoc Agenda, IETF-64 (Vancouver) Location: Junior Ballroom, located in the North Tower, 3rd Floor Sheraton Vancouver Wall Centre 1088 Burrard Street (This is one of the "satellite" conference hotels for this meeting, so folks may need to take a taxi or shuttle bus to reach the event, but it should be quite close) Date/Time: Friday, November 11, 1-5 pm 1:00 Welcome/Agenda Bash A) Current Work Overview SIP Community 1:10 Columbia University (Schulzrinne??) 1:20 College of William and Mary (Bryan) 1:30 Avaya/Nimcat (Matthews) Others B) Topic Discussions Use Cases and Requirements 1:40 Discussion leading to list on screen -- brain storming among the group what do we want to do with this technology? P2P systems and structure 2:00 Overview of various existing P2P Systems (TBD) Discussion of P2P Systems 2:15 SIP based vs. DHT based discussion Architecture/Hierarchy 2:30 UAs as nodes or proxies as nodes discussion 2:40 Interconnect between P2P groups discussion 2:50 15 minute break Identity, Security and Reliability 3:05 What are the open identity and security problems? (Jennings??) 3:15 Identity, Security and Reliability discussion Services 3:40 P2P Services (Tomsu) 3:50 Services discussion Currently unscheduled : 4:00 - 4:30 C) Direction for the future Interest for future work/where to go from here? 4:30 Vote by show of hands of interest in various areas perhaps second vote where each picks one or two most interesting Identifying use cases Identifying requirements Basic Protocol Design for P2P Ad-Hoc P2P Non-Realtime (email, vmail, other?) Distributed Identity P2P Specific Security P2P Specific Reliability Advanced Features in P2P Disaster recovery Hierarchy (beyond just ensuring we allow it) P2P SIP for nodes P2P SIP between servers Brain storm on further topics PLEASE LET ME KNOW MORE ITEMS FOR THIS LIST Going Forward 4:45 Do we have enough work for a working group? Do we want one? Discussion of what to do, planning for next meeting From threelions0916 at yahoo.com.cn Tue Oct 18 04:35:32 2005 From: threelions0916 at yahoo.com.cn (threelions) Date: Tue Oct 18 04:35:56 2005 Subject: [p2p-sip] about DHT in p2p sip Message-ID: <005901c5d3be$e9f37260$6318080a@cnc.intra> Hello£¬every one, I am a new guy to the p2p sip mailing list, very glad to meet you all . I have read the Internet draft" A P2P Approach to SIP Registration draft-bryan-sipping-p2p-01 ¡±£¬this draft use the chord like DHT as the p2p algorithm, DHT must maintain a structured p2p overlay on the IP network, so the join and leave of node will put a processing burden on the other nodes. and we know computers go online and offline frequently, it's said the average online time of pc on Internet is 1 hour, if the p2p network is big enough that several thousands of node are in the chord ring, then the change of chord topology is very frequent, this will greatly reduce the efficiency of chord. so my question is if the p2p sip using DHT mainly focus on the enterprise network, not Internet ? or is there any other methods that can be used to solve the efficiency problem? regards =============================== Michael Liu new technology department china netcom shanghai branch UPT:(86-21)61125030 Email: threelions0916@yahoo.com.cn msn:threelions@sina.com CCIE#13438 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051018/c54b98f8/attachment.html From bryan at ethernot.org Tue Oct 18 10:18:14 2005 From: bryan at ethernot.org (David A. Bryan) Date: Tue Oct 18 10:18:30 2005 Subject: [p2p-sip] about DHT in p2p sip In-Reply-To: <005901c5d3be$e9f37260$6318080a@cnc.intra> References: <005901c5d3be$e9f37260$6318080a@cnc.intra> Message-ID: <8b2769930510180718mba645d9n795f311e5d4b21ca@mail.gmail.com> There has definitely been some discussion about different mechanisms on this list and among the participants. I choose Chord in the draft you mentioned because it is one of the most common, as well as best understood DHT algorithms, so it made the draft a bit clearer I think, since lots of people understand Chord already. I also think it is very well suited to the enterprise space. Chord does place some burden on the nodes for leaves and joins, although the developers of Chord also worked to make it as efficient as possible under those circumstances. It also has some issues with partitioning. I think there are certainly other DHT systems that will make sense as well -- personally I like the idea that different systems could be used, but also think we need to do it in a way that is standardized to make sure different nodes can interoperate -- if every manufacturer uses a different DHT, it would be unlikely any devices would be able to interoperate. I guess the answer is that there certainly different methods one could use, and different methods likely have tradeoffs in terms of simplicity, efficiency, scalability and lookup speed. Chord is just one possibility. David On 10/18/05, threelions wrote: > > > Hello?every one, I am a new guy to the p2p sip mailing list, very glad to > meet you all . > > I have read the Internet draft" A P2P Approach to SIP Registration > draft-bryan-sipping-p2p-01 "?this draft use the chord like DHT as the p2p > algorithm, DHT must maintain a structured p2p overlay on the IP network, so > the join and leave of node will put a processing burden on the other nodes. > and we know computers go online and offline frequently, it's said the > average online time of pc on Internet is 1 hour, if the p2p network is big > enough that several thousands of node are in the chord ring, then the change > of chord topology is very frequent, this will greatly reduce the efficiency > of chord. > > so my question is if the p2p sip using DHT mainly focus on the enterprise > network, not Internet ? or is there any other methods that can be used to > solve the efficiency problem? > > regards > > > =============================== > Michael Liu > new technology department > china netcom shanghai branch > UPT:(86-21)61125030 > Email: threelions0916@yahoo.com.cn > msn:threelions@sina.com > CCIE#13438 > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > From sgilchrist at connetcom.com Tue Oct 18 10:32:30 2005 From: sgilchrist at connetcom.com (Seamus Gilchrist) Date: Tue Oct 18 10:33:12 2005 Subject: [p2p-sip] [P2P SIP] Hierarchical P2P architecture In-Reply-To: <8b276993050902073775bcfe7@mail.gmail.com> Message-ID: <200510181432.j9IEWdsv005051@cs.columbia.edu> When trying to access the paper "Hierarchical P2P systems" got a not found returned (The requested URL /~btroup/P2P/papers/Hp2p.pdf was not found on this server.). Is this paper still available, if not could someone forward a copy, Thanks, Seamus -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan Sent: Friday, September 02, 2005 10:37 AM To: zze-BAILLY Marc RD-CORE-LAN Cc: p2p-sip@cs.columbia.edu Subject: Re: [p2p-sip] [P2P SIP] Hierarchical P2P architecture I definitely agree this is important. I think there is even a slightly more fundamental issue touched on here that needs to be discussed, which is interconnection of groups (realms?) of P2P SIP users. One way (and one I think is a good one) is to interconnect them in a P2P way, but we should also discuss other approaches, such as nodes that participate in each realm and serve as "gateways" between them, or even techniques using the PSTN to bridge (ugh), etc. Also related to this, this list has touched on at least 3 different applications but using similar routing technology -- connecting nodes, interconnecting groups of nodes, and using P2P to load balance servers. I think it would be interesting to see if, at all possible, we can use the same protocol for all applications (maybe not, but it would nice!) --David On 9/2/05, zze-BAILLY Marc RD-CORE-LAN wrote: > > The current work has shown 2 main approaches to add P2P to SIP > architecture > > - P2P SIP: use SIP as the protocol of the P2P layer (Bryan, Jennings, > Schulzrinne approach) and with of course SIP as the above layer for call > control > - SIP P2P: use SIP only at the call control layer and let P2P layer use > its own protocol, the two (SIP and P2P layer being glued by an interface > typically the location service interface (Johnston approach) > Lots of rationales seem to oppose these two approaches. > > But using a 2 level hierarchical P2P model, it seems that we could > combine these 2 views. > > This idea of hierarchical P2P was already proposed in section 6.4.1 of > Singh and Schulzrinne's paper. > (http://www1.cs.columbia.edu/~kns10/publication/sip-p2p-design.pdf). > > On this topic about hierarchical P2P systems, there is an interesting > paper called "Hierarchical P2P systems" > (http://www.eurecom.fr/~btroup/P2P/papers/Hp2p.pdf). One section > presents some adaptations to Chord algorithm which could be done to > implement a top level DHT : > [Section 4.2] "In the top-level overlay network, each "node" is actually > a group of peers. This implies that the top-level lookup system must > manage an overlay of groups, each of which is represented by a set of > superpeers that may fail independently from the group they belong to. > Chord requires some adaptations for being used in the top-level overlay > network and managing groups instead of nodes." > > Our idea would be to use P2P SIP (with these adaptations) at the top > level for interconnection routing but let domains use their own SIP P2P > or even not a P2P approach. > Regarding this top level DHT used for inter domains routing, there are > two approaches: > - The set of nodes responsible for a domain joins this DHT with a random > ID and register their domain on KeyID = HASH(domain.com). > - The set of nodes responsible for a domain joins this DHT with the ID = > HASH(domain.com). > > We would privilege the second approach because it better takes > heterogeneity in sub networks size into account: If a set of peers from > a very small network in the top level DHT is responsible for storing the > association between AOR and contact SIP for a domain with a large amount > of users, this set of peers risks to be overloaded (maybe this problem > could be avoided thanks to caching mechanism). > > This architecture seems to tailor the benefits of the 2 approach (P2P > SIP and SIP P2P): > - offer standardized interconnection to isolated islands (which is, I > guess, one of the goals of the P2P Sip WG) in a P2P way > - does not preclude the use of P2P SIP in a domain > - does not preclude the use of optimized P2P layer protocol (in a > specific environment for example mobile or wifi network) > - does not preclude to connect centralized, by nature, PSTN GW > > This would mean that we must continue the on-going work of P2P SIP for > him to be applied in a SIP P2P world but extend it with a top level > overlay view for interconnection. > > What do you think of this vision? > > Best regards. > Marc Bailly > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From marc1.bailly at rd.francetelecom.com Tue Oct 18 10:37:51 2005 From: marc1.bailly at rd.francetelecom.com (BAILLY Marc RD-CORE-LAN) Date: Tue Oct 18 10:38:52 2005 Subject: [p2p-sip] [P2P SIP] Hierarchical P2P architecture Message-ID: Hi, This paper is now available on : http://cis.poly.edu/~ross/papers/HierarchicalP2P.pdf This link is also mentionned on www.p2psip.org website. Best regards, Marc -----Message d'origine----- De : Seamus Gilchrist [mailto:sgilchrist@connetcom.com] Envoy? : mardi 18 octobre 2005 16:33 ? : 'David A. Bryan'; BAILLY Marc RD-CORE-LAN Cc : p2p-sip@cs.columbia.edu Objet : RE: [p2p-sip] [P2P SIP] Hierarchical P2P architecture When trying to access the paper "Hierarchical P2P systems" got a not found returned (The requested URL /~btroup/P2P/papers/Hp2p.pdf was not found on this server.). Is this paper still available, if not could someone forward a copy, Thanks, Seamus -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan Sent: Friday, September 02, 2005 10:37 AM To: zze-BAILLY Marc RD-CORE-LAN Cc: p2p-sip@cs.columbia.edu Subject: Re: [p2p-sip] [P2P SIP] Hierarchical P2P architecture I definitely agree this is important. I think there is even a slightly more fundamental issue touched on here that needs to be discussed, which is interconnection of groups (realms?) of P2P SIP users. One way (and one I think is a good one) is to interconnect them in a P2P way, but we should also discuss other approaches, such as nodes that participate in each realm and serve as "gateways" between them, or even techniques using the PSTN to bridge (ugh), etc. Also related to this, this list has touched on at least 3 different applications but using similar routing technology -- connecting nodes, interconnecting groups of nodes, and using P2P to load balance servers. I think it would be interesting to see if, at all possible, we can use the same protocol for all applications (maybe not, but it would nice!) --David On 9/2/05, zze-BAILLY Marc RD-CORE-LAN wrote: > > The current work has shown 2 main approaches to add P2P to SIP > architecture > > - P2P SIP: use SIP as the protocol of the P2P layer (Bryan, Jennings, > Schulzrinne approach) and with of course SIP as the above layer for > call control > - SIP P2P: use SIP only at the call control layer and let P2P layer > use its own protocol, the two (SIP and P2P layer being glued by an > interface typically the location service interface (Johnston approach) > Lots of rationales seem to oppose these two approaches. > > But using a 2 level hierarchical P2P model, it seems that we could > combine these 2 views. > > This idea of hierarchical P2P was already proposed in section 6.4.1 of > Singh and Schulzrinne's paper. > (http://www1.cs.columbia.edu/~kns10/publication/sip-p2p-design.pdf). > > On this topic about hierarchical P2P systems, there is an interesting > paper called "Hierarchical P2P systems" > (http://www.eurecom.fr/~btroup/P2P/papers/Hp2p.pdf). One section > presents some adaptations to Chord algorithm which could be done to > implement a top level DHT : > [Section 4.2] "In the top-level overlay network, each "node" is > actually a group of peers. This implies that the top-level lookup > system must manage an overlay of groups, each of which is represented > by a set of superpeers that may fail independently from the group they belong to. > Chord requires some adaptations for being used in the top-level > overlay network and managing groups instead of nodes." > > Our idea would be to use P2P SIP (with these adaptations) at the top > level for interconnection routing but let domains use their own SIP > P2P or even not a P2P approach. > Regarding this top level DHT used for inter domains routing, there are > two approaches: > - The set of nodes responsible for a domain joins this DHT with a > random ID and register their domain on KeyID = HASH(domain.com). > - The set of nodes responsible for a domain joins this DHT with the ID > = HASH(domain.com). > > We would privilege the second approach because it better takes > heterogeneity in sub networks size into account: If a set of peers > from a very small network in the top level DHT is responsible for > storing the association between AOR and contact SIP for a domain with > a large amount of users, this set of peers risks to be overloaded > (maybe this problem could be avoided thanks to caching mechanism). > > This architecture seems to tailor the benefits of the 2 approach (P2P > SIP and SIP P2P): > - offer standardized interconnection to isolated islands (which is, I > guess, one of the goals of the P2P Sip WG) in a P2P way > - does not preclude the use of P2P SIP in a domain > - does not preclude the use of optimized P2P layer protocol (in a > specific environment for example mobile or wifi network) > - does not preclude to connect centralized, by nature, PSTN GW > > This would mean that we must continue the on-going work of P2P SIP for > him to be applied in a SIP P2P world but extend it with a top level > overlay view for interconnection. > > What do you think of this vision? > > Best regards. > Marc Bailly > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From kumarb at research.panasonic.com Tue Oct 18 20:45:05 2005 From: kumarb at research.panasonic.com (Brijesh Kumar) Date: Tue Oct 18 20:46:10 2005 Subject: [p2p-sip] [P2P SIP] Hierarchical P2P architecture Message-ID: <9412f93bb9.93bb99412f@pintlmail.MITL.Research.Panasonic.COM> Hi Guys: As previously mentioned on this list, my colleague Mahfuz, and I have written a design of p2p sip using hierarchical DHT. We were aiming to submit as IETF draft before the cut-off date of 17 October. The draft was completed sometime back, but we could not get our internal publication approval in time, and hence unable to release it to the list. But, will do so as and when we can. cheers, --bk ----- Original Message ----- From: BAILLY Marc RD-CORE-LAN Date: Tuesday, October 18, 2005 10:37 am Subject: RE: [p2p-sip] [P2P SIP] Hierarchical P2P architecture > > Hi, > > This paper is now available on : > http://cis.poly.edu/~ross/papers/HierarchicalP2P.pdf > > This link is also mentionned on www.p2psip.org website. > > Best regards, > > Marc > > -----Message d'origine----- > De : Seamus Gilchrist [sgilchrist@connetcom.com] > Envoy? : mardi 18 octobre 2005 16:33 > ? : 'David A. Bryan'; BAILLY Marc RD-CORE-LAN > Cc : p2p-sip@cs.columbia.edu > Objet : RE: [p2p-sip] [P2P SIP] Hierarchical P2P architecture > > > When trying to access the paper "Hierarchical P2P systems" got a > not found returned (The requested URL /~btroup/P2P/papers/Hp2p.pdf > was not found on this server.). > > Is this paper still available, if not could someone forward a copy, > > Thanks, > > Seamus > > -----Original Message----- > From: p2p-sip-bounces@cs.columbia.edu > [p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan > Sent: Friday, September 02, 2005 10:37 AM > To: zze-BAILLY Marc RD-CORE-LAN > Cc: p2p-sip@cs.columbia.edu > Subject: Re: [p2p-sip] [P2P SIP] Hierarchical P2P architecture > > I definitely agree this is important. I think there is even a > slightly more fundamental issue touched on here that needs to be > discussed, which is interconnection of groups (realms?) of P2P SIP > users. One way (and one I think is a good one) is to interconnect > them in a P2P way, but we should also discuss other approaches, > such as nodes that participate in each realm and serve as > "gateways" between them, or even techniques using the PSTN to > bridge (ugh), etc. > > Also related to this, this list has touched on at least 3 > different applications but using similar routing technology -- > connecting nodes, interconnecting groups of nodes, and using P2P > to load balance servers. I think it would be interesting to see > if, at all possible, we can use the same protocol for all > applications (maybe not, but it would nice!) > > --David > > > > On 9/2/05, zze-BAILLY Marc RD-CORE-LAN > wrote: > > > > The current work has shown 2 main approaches to add P2P to SIP > > architecture > > > > - P2P SIP: use SIP as the protocol of the P2P layer (Bryan, > Jennings, > > Schulzrinne approach) and with of course SIP as the above layer > for > > call control > > - SIP P2P: use SIP only at the call control layer and let P2P > layer > > use its own protocol, the two (SIP and P2P layer being glued by > an > > interface typically the location service interface (Johnston > approach) > > Lots of rationales seem to oppose these two approaches. > > > > But using a 2 level hierarchical P2P model, it seems that we > could > > combine these 2 views. > > > > This idea of hierarchical P2P was already proposed in section > 6.4.1 of > > Singh and Schulzrinne's paper. > > (http://www1.cs.columbia.edu/~kns10/publication/sip-p2p-design.pdf). > > > > On this topic about hierarchical P2P systems, there is an > interesting > > paper called "Hierarchical P2P systems" > > (http://www.eurecom.fr/~btroup/P2P/papers/Hp2p.pdf). One section > > presents some adaptations to Chord algorithm which could be done > to > > implement a top level DHT : > > [Section 4.2] "In the top-level overlay network, each "node" is > > actually a group of peers. This implies that the top-level > lookup > > system must manage an overlay of groups, each of which is > represented > > by a set of superpeers that may fail independently from the > group they belong to. > > Chord requires some adaptations for being used in the top-level > > overlay network and managing groups instead of nodes." > > > > Our idea would be to use P2P SIP (with these adaptations) at the > top > > level for interconnection routing but let domains use their own > SIP > > P2P or even not a P2P approach. > > Regarding this top level DHT used for inter domains routing, > there are > > two approaches: > > - The set of nodes responsible for a domain joins this DHT with > a > > random ID and register their domain on KeyID = HASH(domain.com). > > - The set of nodes responsible for a domain joins this DHT with > the ID > > = HASH(domain.com). > > > > We would privilege the second approach because it better takes > > heterogeneity in sub networks size into account: If a set of > peers > > from a very small network in the top level DHT is responsible > for > > storing the association between AOR and contact SIP for a domain > with > > a large amount of users, this set of peers risks to be > overloaded > > (maybe this problem could be avoided thanks to caching mechanism). > > > > This architecture seems to tailor the benefits of the 2 approach > (P2P > > SIP and SIP P2P): > > - offer standardized interconnection to isolated islands (which > is, I > > guess, one of the goals of the P2P Sip WG) in a P2P way > > - does not preclude the use of P2P SIP in a domain > > - does not preclude the use of optimized P2P layer protocol (in > a > > specific environment for example mobile or wifi network) > > - does not preclude to connect centralized, by nature, PSTN GW > > > > This would mean that we must continue the on-going work of P2P > SIP for > > him to be applied in a SIP P2P world but extend it with a top > level > > overlay view for interconnection. > > > > What do you think of this vision? > > > > Best regards. > > Marc Bailly > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > From threelions0916 at yahoo.com.cn Wed Oct 19 05:52:31 2005 From: threelions0916 at yahoo.com.cn (threelions) Date: Wed Oct 19 05:55:09 2005 Subject: [p2p-sip] about DHT in p2p sip References: <005901c5d3be$e9f37260$6318080a@cnc.intra> <8b2769930510180718mba645d9n795f311e5d4b21ca@mail.gmail.com> Message-ID: <000c01c5d492$d5d18900$6318080a@cnc.intra> thank david for the quick response, it seems a little funny that DHT were introduced to solve the problem of unstructured p2p algorithm, such as the limited scalability because of too much broadcast and blind search . but we learn from practice that the pure unstructured or hybrid unstructured p2p such as glutenna$B!"(Bkazza$B!"(Bskype can support millions of people simulteneously online , however no DHT based p2p application can do this until now. I want to learn from david and other experts if I want to build a large p2p network for service provider , is the unstructured or hybrid unstructured p2p algorithm the practical choice? or some dht algorithm can do this in the near future? regards. Michael ----- Original Message ----- From: "David A. Bryan" To: "threelions" Cc: Sent: Tuesday, October 18, 2005 10:18 PM Subject: Re: [p2p-sip] about DHT in p2p sip > There has definitely been some discussion about different mechanisms > on this list and among the participants. I choose Chord in the draft > you mentioned because it is one of the most common, as well as best > understood DHT algorithms, so it made the draft a bit clearer I think, > since lots of people understand Chord already. I also think it is very > well suited to the enterprise space. > > Chord does place some burden on the nodes for leaves and joins, > although the developers of Chord also worked to make it as efficient > as possible under those circumstances. It also has some issues with > partitioning. I think there are certainly other DHT systems that will > make sense as well -- personally I like the idea that different > systems could be used, but also think we need to do it in a way that > is standardized to make sure different nodes can interoperate -- if > every manufacturer uses a different DHT, it would be unlikely any > devices would be able to interoperate. > > I guess the answer is that there certainly different methods one could > use, and different methods likely have tradeoffs in terms of > simplicity, efficiency, scalability and lookup speed. Chord is just > one possibility. > > David > > On 10/18/05, threelions wrote: > > > > > > Hello$B!$(Bevery one, I am a new guy to the p2p sip mailing list, very glad to > > meet you all . > > > > I have read the Internet draft" A P2P Approach to SIP Registration > > draft-bryan-sipping-p2p-01 "$B!$(Bthis draft use the chord like DHT as the p2p > > algorithm, DHT must maintain a structured p2p overlay on the IP network, so > > the join and leave of node will put a processing burden on the other nodes. > > and we know computers go online and offline frequently, it's said the > > average online time of pc on Internet is 1 hour, if the p2p network is big > > enough that several thousands of node are in the chord ring, then the change > > of chord topology is very frequent, this will greatly reduce the efficiency > > of chord. > > > > so my question is if the p2p sip using DHT mainly focus on the enterprise > > network, not Internet ? or is there any other methods that can be used to > > solve the efficiency problem? > > > > regards > > > > > > =============================== > > Michael Liu > > new technology department > > china netcom shanghai branch > > UPT:(86-21)61125030 > > Email: threelions0916@yahoo.com.cn > > msn:threelions@sina.com > > CCIE#13438 > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿðèb‹˜j(ÿÿÿÿÿÿÿñÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿþm§ÿÿræj)ÿɨh£÷(›ÿâ From salman at cs.columbia.edu Fri Oct 28 13:16:23 2005 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Fri Oct 28 13:16:29 2005 Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer Internet Telephony Message-ID: We have attempted to compile the requirements for SIP-based peer-to-peer Internet telephony in a draft. It is available at: http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00.txt Title: Requirements for SIP-based Peer-to-Peer Internet Telephony Abstract: This document defines requirements for designing peer-to-peer voice, text, and real-time multimedia communication system protocols. Comments are requested. Regards, Salman, Henning, Eunsoo, Kishore From matthewsp at avaya.com Fri Oct 28 18:35:33 2005 From: matthewsp at avaya.com (Matthews, Philip (Philip)) Date: Fri Oct 28 18:35:50 2005 Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony Message-ID: [I am posting this to the P2P-SIP mailing list only (and not SIPPING), since it is my belief that that list provides the most appropriate discussion forum.] I think this is a great start on the requirements discussion. My thanks to the authors for producing this. Here are some quick comments. Hope to generate some more in-depth comments next week. > 4.3. DHT Changeability > The protocol(s) for maintaining the peer-to-peer network SHOULD be > flexible to accommodate different DHT algorithms. I totally agree with this. From my limited investigation of the DHT world, I see things just changing too fast to have any hope that today's DHT will still be tomorrow's DHT of choice. > 4.5. NAT and Firewall Traversal > R1. The peer-to-peer system SHOULD distribute the functionality of > NAT and firewall traversal servers to the end-points. I don't see why this must be a requirement. Your other requirements talk about being flexible on where services are located (i.e. centralized or distributed). Given this flexibility, which I agree with, why require that a certain service be distributed? Why not leave the choice up to the builder of the particular P2P overlay network? If that builder wants to provide a centralized NAT and Firewall Traversal scheme, why not let him? As I see it, a centralized service is one that is located on just a small number of peers, while a distributed service is one that is located on a large number of peers. The same lookup scheme could be used for both, so an arbitrary peer doesn't really need to know whether a service is centralized or distributed. So why say that a certain service must be distributed? On the other hand, I would agree that the design should SUPPORT making the NAT and Firewall Traversal distributable, but I think you have already covered that in 4.1. > 5.4.1. Centralized Lookup > Value-added services such as reliable voicemail storage can be > provided by a central authority in a P2P network. The system SHOULD > allow the peers to efficiently locate the centralized service > providers or resources. This is just a minor comment. The first sentence seems to imply that voicemail is preferably implemented as a centralized service. I disagree with that implication, and suggest that the first sentence be reworded or simply removed. I DO agree with the requirement in the second sentence. > 6.1. Support for different DHTs > Any protocol specification SHOULD be able to incorporate different > DHT algorithms based on the P2P service provider requirements. Isn't this the same as requirement 4.3?? - Philip Matthews Nimcat Networks (now a part of Avaya) PS. Please note that my e-mail address has recently changed to matthewsp@avaya.com Mail sent to my old address (matthews@nimcatnetworks.com) will be forwarded for a period, but will eventually be returned. -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of Salman Abdul Baset Sent: October 28, 2005 13:16 To: sipping@ietf.org Cc: p2p-sip@cs.columbia.edu Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony We have attempted to compile the requirements for SIP-based peer-to-peer Internet telephony in a draft. It is available at: http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00 .txt Title: Requirements for SIP-based Peer-to-Peer Internet Telephony Abstract: This document defines requirements for designing peer-to-peer voice, text, and real-time multimedia communication system protocols. Comments are requested. Regards, Salman, Henning, Eunsoo, Kishore _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From salman at cs.columbia.edu Sun Oct 30 01:09:03 2005 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sun Oct 30 01:14:06 2005 Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony In-Reply-To: References: Message-ID: Thanks for your comments. Please see my comments inline: > > 4.5. NAT and Firewall Traversal > > R1. The peer-to-peer system SHOULD distribute the functionality of > > NAT and firewall traversal servers to the end-points. > > I don't see why this must be a requirement. Your other requirements talk > about being flexible on where services are located (i.e. centralized or > distributed). Given this flexibility, which I agree with, why require > that > a certain service be distributed? Why not leave the choice up to the > builder of > the particular P2P overlay network? If that builder wants to provide a > centralized NAT and Firewall Traversal scheme, why not let him? I agree that the choice should be left to the bundler of the P2P overlay network for deciding which services should be centralized and which should be distributed. However, at some point the P2P bundler will need to decide whether the overlay network it is building has degenerated into a typical SIP-based network and still being marketed as P2P:) > On the other hand, I would agree that the design should SUPPORT making > the NAT and > Firewall Traversal distributable, but I think you have already covered > that in 4.1. We think that distributed NAT and firewall traversal is one of the key motivations to build a P2P overlay, so we decided to keep it as a seperate requirement. There are two requirements in this section. I think one option is to delete R1 and keep R2 which says: "A peer with NAT and firewall traversal capabilities SHOULD be selected such that it does not introduce significant delay between the communicating peers." The other option is to include this section as a subsection of 4.1. > > > 5.4.1. Centralized Lookup > > Value-added services such as reliable voicemail storage can be > > provided by a central authority in a P2P network. The system > SHOULD > > allow the peers to efficiently locate the centralized service > > providers or resources. > > This is just a minor comment. The first sentence seems to imply that > voicemail > is preferably implemented as a centralized service. I disagree with that > implication, and suggest that the first sentence be reworded or simply > removed. > > I DO agree with the requirement in the second sentence. The sentence says '...reliable voicemail storage can be provided...'. I guess the 'can' should be changed to 'might'. > > 6.1. Support for different DHTs > > Any protocol specification SHOULD be able to incorporate different > > DHT algorithms based on the P2P service provider requirements. > > Isn't this the same as requirement 4.3?? We wanted to emphasize that a 'P2P Protocol Spec' must support multiple DHTs. Since this requirement fell under 'Architecture' and 'Protocol Spec Requirements', we decided to keep it in both. I think cross-referencing the sections will be helpful. regards, -- Salman Baset > > - Philip Matthews > Nimcat Networks (now a part of Avaya) > > PS. Please note that my e-mail address has recently changed to > matthewsp@avaya.com > Mail sent to my old address (matthews@nimcatnetworks.com) will > be forwarded for a period, but will eventually be returned. > > > > -----Original Message----- > From: p2p-sip-bounces@cs.columbia.edu > [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of Salman Abdul Baset > Sent: October 28, 2005 13:16 > To: sipping@ietf.org > Cc: p2p-sip@cs.columbia.edu > Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer > InternetTelephony > > We have attempted to compile the requirements for SIP-based peer-to-peer > Internet telephony in a draft. It is available at: > http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00 > .txt > > Title: Requirements for SIP-based Peer-to-Peer Internet Telephony > Abstract: > This document defines requirements for designing peer-to-peer voice, > text, and real-time multimedia communication system protocols. > > Comments are requested. > > Regards, > Salman, Henning, Eunsoo, Kishore > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > From srisuresh at yahoo.com Fri Oct 21 14:45:46 2005 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Sun Oct 30 09:10:02 2005 Subject: [p2p-sip] Re: SIP does NAT and P2P NAT Message-ID: <20051021184546.24419.qmail@web33304.mail.mud.yahoo.com> Thanks, Henry, for the info. The discussion sounds interesting. I will not be attending the IETF meeting this time. However, I would love to parttake in the e-mail discussions. After reading the e-mail, I just joined the p2p-sip mailing list. Just as an FYI, we are working on submitting revised "Application design guidelines for NAT traversal" draft (draft-ford-behave-app-01.txt) and "State of P2P communication across NATs" draft (draft-srisuresh-behave-p2p-state-01.txt) this weekend. Both these P2P NAT drafts refer the ICE draft. It would be good to include links to these P2P NAT drafts in the P2PSIP web site. regards, suresh --- Henry Sinnreich wrote: > Most here probably already know: NAT traversal for SIP has much in common > with P2P NAT traversal on which there is an excellent recent paper at > http://www.brynosaurus.com/pub/net/p2pnat > > The NAT Check tool http://midcom-p2p.sourceforge.net/ and the results for > many NATs are also very close to the interests of the SIP folks here. > > This paper has a very similar approach to ICE, but may be of special > interest to the P2P SIP folks and should be linked I believe on the > www.p2psip.org web site. ICE and P2PNAT ought to be well cross-referenced. > > Two meetings of common interest at the 64 IETF: > > - "SIP does NAT" on Friday at 8:00; informal in the breakfast area, > - "P2P SIP" Friday 1:00-5:00, > Location: Junior Ballroom, located in the North Tower, 3rd Floor Sheraton > Vancouver Wall Centre 1088 Burrard Street. > > Thanks, Henry > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, October 21, 2005 8:51 AM > To: Chris Boulton; henry@pulver.com; Jonathan Rosenberg; Francois Audet > Cc: Alan Duric; Jon Peterson; Daniel G. Petrie; Alan Johnston; Henning > Schulzrinne; Adrian Georgescu; Jiri Kuthan; Dean Willis > Subject: Re: SIP does NAT > > > Please add Francois Audet to this thread - thanks. > > > On 10/20/05 1:29 AM, "Chris Boulton" wrote: > > > > > Many thanks to Jonathan for the new ICE draft! > > > > [Chris Boulton] yes - thanks Jonathan. > > > > While this goes a long way in solving the problem, the IETF has NAT/FW > > traversal dispersed in far too many WGs and thus there is no (I hate > > this > > word) "program management", sorry to say so... Besides, we still need > > agreement on > > > > - A framework document and reading map, author? > > > > [Chris Boulton] Is this necessary above and beyond what the NAT > > scenarios provide? The document already touches on topics such as > > varying profiles for UA's. If it is truly felt necessary I am more than > > happy to organize and provide a general NAT Framework (such topics as > > the UA profiles would be moved there). This would result in the NAT > > scenarios draft purely being deployment examples. I'd be interested in > > 'folks' opinion on this. > > > > - Examples: The I-D by Chris Boulton and Jonathan Rosenberg, > > > > [Chris Boulton] I will be working to produce a revision by Monday - to > > be followed up after the meeting by another. > > - Cullen Jenning's I-D, > > - Any other? > > > > If you are interested to discuss what I believe to be a crisis, let's > > meet > > Friday 11/11 morning at 8:00 at breakfast. > > > > [Chris Boulton] Unfortunately I am leaving Thursday evening - but would > > be free to chat at any other time. > > > > What do you think; are exceptional actions justified to have SIP do NAT, > > finally? Make a time slot in SIP or SIPPING to discuss before any other > > topics on the agenda? > > > > Thanks again to Jonathan and all authors that are contributing to a > > solution, > > > > Henry > > > > > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Wednesday, October 19, 2005 8:27 PM > > To: henry@pulver.com > > Cc: 'Cullen Jennings'; 'Alan Duric'; 'Peterson, Jon'; 'Daniel G. > > Petrie'; > > 'Alan Johnston'; 'Henning Schulzrinne'; 'Adrian Georgescu'; 'Jiri > > Kuthan'; > > 'Dean Willis'; 'Chris Boulton' > > Subject: Re: SIP does NAT > > > > Sorry for not commenting on this sooner. As you know this is a topic > > near and dear to my heart. I didn't want to post a note without being > > able to report some news, and the news is that I have revised and > > submitted the ICE spec, and spent a huge amount of time on it over the > > last few weeks. I now believe its done and would be happy to ask Colin > > and Joerg to wglc if folks think it would help accelerate. > > > > ALong with the ICE draft was ICE-tcp, which describes a way to basically > > > > have RTP run over tcp. Each endpoint in the call need only be able to > > make an outbound tcp connection to some port on the turn relay. Once you > > > > have something like that, I think it covers a LOT of cases. If you run > > into firewalls that still block outbound tcp, you can try running your > > turn tcp servers on port 80. Now I won't write that in an ietf spec but > > it can be configured with ice-tcp. If that doesn't work, the next step > > would be to get TLS support too. That would reqiure a turn extension. > > Beyond that gets into nasties like HTTP tunneling. I suspect TURN/TLS > > would be good enough. As such, I would support such a work item. I'm not > > > > so sure about tunenls beyond that. As Cullen has pointed out, none of > > that will work terribly well when there is packet loss. I don't know if > > Skype plays games with tcp like parallel connections and fake ACKs. That > > > > would be another possible "work item" but somehow I think would have to > > be done as an individual effort and sent right to rfc-ed, since its > > clearly horrible stuff. > > > > The other thing that needs to be done is complete TURN; its languished > > somewhat as an individual I-D and needs to be finished. I have a plan > > for wrapping it up, and should have a revision out before the deadline > > that puts some sanity around it and its relationship to STUN, and the > > various things we're doing with stun these days. > > > > Per the bits in the thread on anycast; I'd support some work on turn > > server discovery. However, I don't want to send the wrong message to the > > > > industry. TURN/STUN/ICE is, imho enough, and please don't wait for ietf > > to figure out some kind of optimization to shave 25ms off the voice > > latency. So we'd need to be careful about how this is positioned. > > > > > > > > > > > > More below: > > > > Henry Sinnreich wrote: > > > >> Cullen, > >> > >> Thanks for the interest! Here are some topics to discuss: > >> > >> 1. Support for 'legacy' SIP UA: At present most service providers us > > SBC > >> (horrible), when we could recommend such as > >> http://ag-projects.com/MediaProxy.html > > > > Actually, there is something that can be done for legacy PC softphones > > at least. One idea is to have a single-user ICE-agent; it basically runs > > > > on the same PC as the softphone. You point your softphone to it > > (different port on the same host) as the outbound proxy. That little > > ICE-agent acts as a b2bua and implements ICE on behalf of the caller. > > Doesnt work so good for hardphones and TAs. Please don't push this > > outside of the endpoint though; as soon as you do that, you have the > > chance of a nat between the endpoint and this mini-SBC, and that would > > really be bad... > > > >> > >> 2. Many SIP UA and service providers support STUN, but it is a hard > > sell > >> since it is not always effective, and sorry to say, Skype and Google > > Talk > >> will always work. > > > > Right. Thats why there is ICE. > > > >> > >> 3. ICE will always work and there are already pre-standard > > implementations > >> like at http://www.counterpath.com/index.php and Chris Boulton and > > Jonathan > >> Rosenberg have an excellent I-D with detailed examples > >> > > http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-nat-scenarios-02.t > > xt > > > >> > >> 4. Is there a way to get ICE and the NAT Scenarios faster to Last > > Call? > > > > Per above, ICE is done AFAIK and I believe ready to go to WGLC. > > > > Henning had written: > >> I'm sorry to say that a media relay of whatever kind isn't all that > > different from an SBC. > > > > well, that depends on what it is about sbc's that you view as bad. If > > you think the badness is around the fact that there is relay of media, > > then media relays (ala turn) are bad too. But I think its the b2bua and > > transparency issues, security issues, that are bad. ICE/STUN/TURN will > > use media relays when needed but has none of the transparency or > > security issues. Indeed, if you look at the securite considerations > > section in ICE, the voice hammer attack in particular - an SBC helps > > this not one bit. > > > > -Jonathan R. > > > > From dean.willis at softarmor.com Fri Oct 28 01:46:18 2005 From: dean.willis at softarmor.com (Dean Willis) Date: Sun Oct 30 09:10:06 2005 Subject: [p2p-sip] Re: Skype security evaluation: A role model? In-Reply-To: <200510231947.j9NJlMUZ030202@nylon.softarmor.com> References: <200510231947.j9NJlMUZ030202@nylon.softarmor.com> Message-ID: <090D82EC-65D4-4C02-BED0-66040D990354@softarmor.com> On Oct 23, 2005, at 2:42 PM, Henry Sinnreich wrote: > > Add P2PSIP security to the agenda of the P2PSIP BOF at the 64 IETF? Note for the procedurally-oriented: We're not having a BOF at IETF 64. We're having an ad-hoc meeting after IETF 64 at a conveniently nearby facility. I'm getting more excited about P2P with each passing second. But the IETF BOF procedure is the first step to forming a working group, and we don't yet have a consensus, even among ourselves, that this work should be done at the IETF or that it needs its own working group. I suspect it does and it does, but we're not there yet. Maybe we will be after this ad-hoc. -- Dean From jr at tuffit.com Mon Oct 31 05:58:04 2005 From: jr at tuffit.com (John Risson) Date: Mon Oct 31 06:01:39 2005 Subject: [p2p-sip] RE: [P2P SIP] Hierarchical P2P architecture Message-ID: <000801c5de09$f9d22d20$0100000a@tuffit1> There is a new tech report for (sip) location services on hierarchic dhts at http://www.ee.unsw.edu.au/~timm/pubs/reports/index.html#3. The design minimizes the impact of failure - the hierarchy partitions dht failure/recovery traffic. It also improves mobility - objects/users can move to a different part of the dht hierarchy without impacting the root dht. All comments welcome. Rgds . John. -----Original Message----- From: p2p-sip-bounces@cs.columbia.edu [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of David A. Bryan Sent: Friday, September 02, 2005 10:37 AM To: zze-BAILLY Marc RD-CORE-LAN Cc: p2p-sip@cs.columbia.edu Subject: Re: [p2p-sip] [P2P SIP] Hierarchical P2P architecture I definitely agree this is important. I think there is even a slightly more fundamental issue touched on here that needs to be discussed, which is interconnection of groups (realms?) of P2P SIP users. One way (and one I think is a good one) is to interconnect them in a P2P way, but we should also discuss other approaches, such as nodes that participate in each realm and serve as "gateways" between them, or even techniques using the PSTN to bridge (ugh), etc. Also related to this, this list has touched on at least 3 different applications but using similar routing technology -- connecting nodes, interconnecting groups of nodes, and using P2P to load balance servers. I think it would be interesting to see if, at all possible, we can use the same protocol for all applications (maybe not, but it would nice!) --David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20051031/be254523/attachment.html From afisk at speedymail.org Mon Oct 31 15:23:36 2005 From: afisk at speedymail.org (Adam Fisk) Date: Mon Oct 31 15:24:43 2005 Subject: [p2p-sip] dhts Message-ID: <43667D48.70001@speedymail.org> I just wanted to pipe in on the DHT question to caution against the Chord bandwagon. Sure, Chord is nice to reference because most people have heard of it. That's really just because Chord was the first prominent DHT algorithm, though, and that's still it's primary distinguishing characteristic. Other algorithms such as Kademlia are significantly more robust and have less rigid routing schemes, though. We should be clear that Chord should only be referenced *because people know it* and should not seriously be considered for real world implementations. I'd actually prefer it if people stopped referencing Chord in the various drafts simply because it contributed to the misconception that it's a good option. Thanks. -Adam From srisuresh at yahoo.com Mon Oct 31 17:08:52 2005 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Mon Oct 31 17:09:18 2005 Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony In-Reply-To: Message-ID: <20051031220852.1869.qmail@web33302.mail.mud.yahoo.com> First off, good requirements set. Thanks for putting them together. Couple of comemnts on the draft. 1. I would suggest including the draft as a reference in the context of firewall/NAT traversal. The recommendation in the draft about how P2P apps could adapt to traverse NATs would be directly relevant here. Also talked in the draft are security concerns with P2P NAT traversal. 2. Usage Scenarios - Please expand on section 7.1 with a diagram - specifically descrbing a P2P SIP setup as opposed to a traditional SIP. What servers/services are prevalent in traditional SIP setup vs a P2P SIP setup. Additional comments in line below. regards, suresh --- Salman Abdul Baset wrote: > Thanks for your comments. Please see my comments inline: > > > > 4.5. NAT and Firewall Traversal > > > R1. The peer-to-peer system SHOULD distribute the functionality of > > > NAT and firewall traversal servers to the end-points. > > > > I don't see why this must be a requirement. Your other requirements talk > > about being flexible on where services are located (i.e. centralized or > > distributed). Given this flexibility, which I agree with, why require > > that > > a certain service be distributed? Why not leave the choice up to the > > builder of > > the particular P2P overlay network? If that builder wants to provide a > > centralized NAT and Firewall Traversal scheme, why not let him? > [suresh] I too disagree with the requirement, but for a different reason. I beleve, the requirement is that P2P nodes should be able to traverese the FW/NAT devices enroute. Why should the functionality of NAT/firewall traversal servers be distributed to the end-points? And, why is this a requirement? I do not see why services required for P2P shoudl be mandated as part of P2P end nodes. > I agree that the choice should be left to the bundler of the P2P overlay > network for deciding which services should be centralized and which should > be distributed. However, at some point the P2P bundler will need to decide > whether the overlay network it is building has degenerated into a typical > SIP-based network and still being marketed as P2P:) > [suresh] I think, it woudl be a good idea to draw a picture to contrast between a traditional SIP network and a P2P SIP network. Endpoint Identity and location of P2P nodes (and the associated service) is the key distinction, in my opinion. > > On the other hand, I would agree that the design should SUPPORT making > > the NAT and > > Firewall Traversal distributable, but I think you have already covered > > that in 4.1. > > We think that distributed NAT and firewall traversal is one of the key > motivations to build a P2P overlay, so we decided to keep it as a seperate > requirement. [suresh] I agree, NAT and firewall traveral is a key requirement for P2P overlay. > There are two requirements in this section. I think one > option is to delete R1 and keep R2 which says: > > "A peer with NAT and firewall traversal capabilities SHOULD be selected > such that it does not introduce significant delay between the > communicating peers." > [suresh] The above requirement is disctinct from R1, in my opinion. I woudl not suggest eliminating R1. R2 above is similar to Req-3 in , which talks about design guidelines for P2P applications in the context of NAT traversal. > The other option is to include this section as a subsection of 4.1. > [suresh] Please see my comment earlier about rewording R1. > > > > > 5.4.1. Centralized Lookup > > > Value-added services such as reliable voicemail storage can be > > > provided by a central authority in a P2P network. The system > > SHOULD > > > allow the peers to efficiently locate the centralized service > > > providers or resources. > > > > This is just a minor comment. The first sentence seems to imply that > > voicemail > > is preferably implemented as a centralized service. I disagree with that > > implication, and suggest that the first sentence be reworded or simply > > removed. > > > > I DO agree with the requirement in the second sentence. > > The sentence says '...reliable voicemail storage can be provided...'. I > guess the 'can' should be changed to 'might'. > [suresh] That sounds good. > > > > 6.1. Support for different DHTs > > > Any protocol specification SHOULD be able to incorporate different > > > DHT algorithms based on the P2P service provider requirements. > > > > Isn't this the same as requirement 4.3?? > > We wanted to emphasize that a 'P2P Protocol Spec' must support multiple > DHTs. Since this requirement fell under 'Architecture' and 'Protocol Spec > Requirements', we decided to keep it in both. I think cross-referencing > the sections will be helpful. > > regards, > -- > Salman Baset > regards, suresh > > > > > - Philip Matthews > > Nimcat Networks (now a part of Avaya) > > > > PS. Please note that my e-mail address has recently changed to > > matthewsp@avaya.com > > Mail sent to my old address (matthews@nimcatnetworks.com) will > > be forwarded for a period, but will eventually be returned. > > > > > > > > -----Original Message----- > > From: p2p-sip-bounces@cs.columbia.edu > > [mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of Salman Abdul Baset > > Sent: October 28, 2005 13:16 > > To: sipping@ietf.org > > Cc: p2p-sip@cs.columbia.edu > > Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer > > InternetTelephony > > > > We have attempted to compile the requirements for SIP-based peer-to-peer > > Internet telephony in a draft. It is available at: > > http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00 > > .txt > > > > Title: Requirements for SIP-based Peer-to-Peer Internet Telephony > > Abstract: > > This document defines requirements for designing peer-to-peer voice, > > text, and real-time multimedia communication system protocols. > > > > Comments are requested. > > > > Regards, > > Salman, Henning, Eunsoo, Kishore > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > From dhara at research.avayalabs.com Sun Oct 30 10:20:18 2005 From: dhara at research.avayalabs.com (K. Kishore Dhara) Date: Sun Nov 6 10:32:03 2005 Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony In-Reply-To: References: Message-ID: <4364E4B2.6000101@research.avayalabs.com> Philip, Thanks for your comments. My comments inline. Matthews, Philip (Philip) wrote: >[I am posting this to the P2P-SIP mailing list only (and not SIPPING), >since it is my belief that that list provides the most appropriate >discussion forum.] > >I think this is a great start on the requirements discussion. >My thanks to the authors for producing this. > >Here are some quick comments. Hope to generate some more in-depth >comments next week. > > > >>4.3. DHT Changeability >> The protocol(s) for maintaining the peer-to-peer network SHOULD be >> flexible to accommodate different DHT algorithms. >> >> > >I totally agree with this. From my limited investigation of the DHT >world, >I see things just changing too fast to have any hope that today's DHT >will >still be tomorrow's DHT of choice. > > > > >>4.5. NAT and Firewall Traversal >> R1. The peer-to-peer system SHOULD distribute the functionality of >> NAT and firewall traversal servers to the end-points. >> >> > >I don't see why this must be a requirement. Your other requirements talk >about being flexible on where services are located (i.e. centralized or >distributed). Given this flexibility, which I agree with, why require >that >a certain service be distributed? Why not leave the choice up to the >builder of >the particular P2P overlay network? If that builder wants to provide a >centralized NAT and Firewall Traversal scheme, why not let him? > >As I see it, a centralized service is one that is located on just a >small number >of peers, while a distributed service is one that is located on a large >number >of peers. The same lookup scheme could be used for both, so an arbitrary >peer doesn't >really need to know whether a service is centralized or distributed. So >why say that >a certain service must be distributed? > >On the other hand, I would agree that the design should SUPPORT making >the NAT and >Firewall Traversal distributable, but I think you have already covered >that in 4.1. > > > > I agree with you that the general requirement 4.1 should subsume 4.3 R1. >>5.4.1. Centralized Lookup >> Value-added services such as reliable voicemail storage can be >> provided by a central authority in a P2P network. The system >> >> >SHOULD > > >> allow the peers to efficiently locate the centralized service >> providers or resources. >> >> > >This is just a minor comment. The first sentence seems to imply that >voicemail >is preferably implemented as a centralized service. I disagree with that >implication, and suggest that the first sentence be reworded or simply >removed. > > > You are right, we don't mean to imply that voicemail is preferred as a centralized service. Sure, we will reword it to avoid ambiguity. >I DO agree with the requirement in the second sentence. > > > > >>6.1. Support for different DHTs >> Any protocol specification SHOULD be able to incorporate different >> DHT algorithms based on the P2P service provider requirements. >> >> > >Isn't this the same as requirement 4.3?? > > > As I see it, 4.3 is a general requirement on the P2P protocol maintenance to accommodate different DHT algorithms and 6.1 is the specific ability of the protocol to incorporate requirements (?) of P2P service providers, which might include things other than the maintenance of P2P structure. I agree with you that the section headings for 4.3 and 6.1 are misleading. Thanks. Regards, -- Kishore >- Philip Matthews > Nimcat Networks (now a part of Avaya) > >PS. Please note that my e-mail address has recently changed to > matthewsp@avaya.com > Mail sent to my old address (matthews@nimcatnetworks.com) will > be forwarded for a period, but will eventually be returned. > > > >-----Original Message----- >From: p2p-sip-bounces@cs.columbia.edu >[mailto:p2p-sip-bounces@cs.columbia.edu] On Behalf Of Salman Abdul Baset >Sent: October 28, 2005 13:16 >To: sipping@ietf.org >Cc: p2p-sip@cs.columbia.edu >Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer >InternetTelephony > >We have attempted to compile the requirements for SIP-based peer-to-peer >Internet telephony in a draft. It is available at: >http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00 >.txt > >Title: Requirements for SIP-based Peer-to-Peer Internet Telephony >Abstract: >This document defines requirements for designing peer-to-peer voice, >text, and real-time multimedia communication system protocols. > >Comments are requested. > >Regards, >Salman, Henning, Eunsoo, Kishore >_______________________________________________ >p2p-sip mailing list >p2p-sip@cs.columbia.edu >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > >