Hi, Currently, the RELOAD draft specifies one mandatory DHT algorithm, which is a modified version of the Chord DHT algorithm. The reason for specifying a mandatory algorithm is to allow interoperability. It seems that this modified Chord algorithm is mostly useful in small-scale low-churn scenarios. What I am trying to say is that the P2PSIP WG should not forget about other scenarios such as large-scale/medium-scale/high-churn/medium-churn etc. overlay networks. To handle these other scenarios, one either needs to hand-tune the DHT algorithm specifically for each scenario (by setting appropriate values for parameters such as the size of the neighborhood set, the size of the finger table, and stabilization interval) or alternatively, one needs self-tuning behavior. Hand-tuning will be very difficult in practice.
I agree that the P2PSIP work would benefit from HIP. However, regardless of whether HIP is used or not, we would anyway benefit from a DHT algorithm that can adjust its parameters dynamically as the size of the network and/or the churn rate changes. As an alternative to specifying only one DHT algorithm, perhaps the P2PSIP WG could specify at least two DHT algorithms: a simple one which would be easy to implement and which would work well in small, low-churn networks (i.e. the modified Chord algorithm currently specified in the RELOAD draft). Then there could be another, self-tuning algorithm, which would scale also to bigger networks and to networks having higher churn rates. Of course, ideally there would be only one algorithm. Jouni Henry Sinnreich wrote: >> Any comments? >> >> Jouni > > Actually, I would argue that a new P2PSIP protocol may be useful but not > necessarily mandatory at all and here is why: > > 1. Any P2P solution must work for more than SIP, especially with for other > Rich Internet Applications (RIA) and older ones as well: Application level > multicast, blogging, social networks, wikis, video, range search, not > invented yet. > > 2. This is possible only by using HIP for NAT traversal for _all_ > application level protocols. > > 3. Using HIP, the existing native p2p protocols can be used such as Bamboo, > with SIP as one of several applications on top of the p2p overlay. No other > special protocols are required, though one may be useful. My problem is I > have not found any reason why a special protocol would be required of we > just use the following: > > Application > ======================= > SIP/RTP > ======================= > Any P2P optimally suitable for the specific application > ======================= > HIP with NAT traversal > ======================= > UDP/TCP > ======================= > IP > ======================= > > I would be interested to hear what else is required for SIP in particular. > > Thanks, Henry > > On 7/22/08 11:41 PM, "Jouni Mäenpää" <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> As pointed out in [1], DHT-based overlays usually need to be configured >> statically (e.g. by assuming a certain churn level and network size). >> The problem is setting the parameters so that the overlay achieves the >> desired reliability and performance even in challenging conditions, such >> as under heavy churn. This naturally results in high cost in the common >> case or alternatively, poor performance or even network partitioning in >> worse than expected conditions. This kind of hand-tuning rarely works in >> real settings because it requires perfect knowledge about the future. >> >> In my opinion, the P2PSIP WG should specify a self-tuning DHT algorithm >> which would adapt to the operating conditions (e.g. network size and >> churn rate). This would make it possible to use the DHT in a wide range >> of environments instead of e.g. only small-scale low-churn networks. >> >> Any comments? >> >> Jouni >> >> [1] R. Mahajan, M. Castro, and A. Rowstron. Controlling the cost of >> reliability in peer-to-peer overlays. In IPTPS, 2003 >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
