Yes, this is also out of scope for the WG. -Ekr
2010/3/17 <[email protected]> > > DHT/reload discussed here are used for build trackers of a streaming > system, where the resources are chunk/piece of data other than users. > > > Wang Russell > > > > *Eric Rescorla <[email protected]>* > > 2010-03-17 22:12 > 收件人 > [email protected] > 抄送 > jc <[email protected]>, "[email protected]" <[email protected]>, > [email protected] > 主题 > Re: [P2PSIP] 答复: Re: Is P2PSIP RELOAD not suitable to be leverage for both > P2P Live Streaming and VoD Service? > > > > > This all seems really off topic for this WG. The charter of P2PSIP > explicitly excludes > any work on this kind of media sharing: > > > 1. Issues specific to applications other than locating users and > resources for SIP-based communications and presence. > > -Ekr > > > 2010/3/17 <*[email protected]* <[email protected]>> > > I think whatever the centralized or distributed tracker you chose, > if you must deal with billions of users's access, they're the same. The > centralized tracker must be deployed in distributed or so-called 'cluster' > mode, DHT is just one kind of distributed algorithm, not so special... > And futhermore, the DHT algorithm does not always mean 'poor > performance', we have implemented one kind of DHT algorithm suitable for > stable network, its lookup cost is one hop(thousands nodes) or two > hop(millions nodes), and the algorithm released as a plug-in of RELOAD > protocol. > The similar algorithm you can found in amazon's dynamo or the memcahce > project, and there's also some other constant complexity DHT algorithm. > > > > Russell Wang > > > > *jc <**[email protected]* <[email protected]>*>* > 发件人: *[email protected]* <[email protected]> > > 2010-03-16 08:58 > > 收件人 > Bruce Lowekamp <*[email protected]* <[email protected]>> > 抄送 > "*[email protected]* <[email protected]>" <*[email protected]* <[email protected]> > > > 主题 > Re: [P2PSIP] Is P2PSIP RELOAD not suitable to be leverage for both > P2P Live Streaming and VoD Service? > > > > > > > The largest overlay i've seen where every node participated in storage and > routing was ~1.6M. They operate best under ~650K. At about 1M the routing > times get into the minutes. You would need to create and ad-hoc overlay for > every stream. I've implemented a multicast layer that does this over a DHT. > The DHT is the signaling layer used to setup these ad-hoc overlays(groups). > RELOAD could perform the signaling, rendezvous setup, multicast grouping > storage but not too much more. > > On Mar 15, 2010, at 8:10 PM, Bruce Lowekamp wrote: > > So substituting the terms used in RELOAD, this is exactly my point. > draft-hu-ppsp-tracker-dht-performance-comparison assumes 20M peers, i.e. > nodes used in routing, and bases latency calculations on that number. Not > 57K. The draft further works out that with 20M peers storing data, each > needs to store 0.01 of a resource. > > Even if you do the calculations with a reasonable number of peers (routing > nodes), the dht overlay will still obviously have higher latency than a > single-server based solution. You select a dht overlay for different > reasons than you would select a central server-based solution. > > Bruce > > > On Mon, Mar 15, 2010 at 3:27 PM, jc > <*[email protected]*<[email protected]>> > wrote: > You need 57,142.857 nodes to route 20M of peer traffic. This is the > algorithm we used in fasttrack and is the same as in skype. This is a > maximum capacity scenario. > > Sent from my iPhone > > On Mar 15, 2010, at 6:32 PM, Bruce Lowekamp > <*[email protected]*<[email protected]>> > wrote: > > They scale fine, but there is a point beyond which adding additional peers > to the overlay routing merely adds latency. Don't have time to look up the > references now, but there are a number of papers discussing the advantages > of different numbers of peers (superpeers in a lot of systems) needed for > overlay routing. You don't need 10M. > > Bruce > > > On Mon, Mar 15, 2010 at 11:55 AM, jc < <[email protected]>* > [email protected]* <[email protected]>> wrote: > > On Mar 15, 2010, at 3:32 PM, Bruce Lowekamp wrote: > > The performance comparison draft compares the performance of a centralized > lookup server with a P2P DHT system with 10M peers. Since those address > entirely different use cases, and no one would ever deploy a 10M peer > distributed tracker, it's not clear what the point of the comparison is. > This has nothing to do with RELOAD. > > There are active distributed trackers w/ > 1M peers. Why would you not > deploy a 10M user distributed tracker? They do inherently scale infinitely > by nature. > > > Bruce > > > > On Mon, Mar 15, 2010 at 12:55 AM, World < <[email protected]>* > [email protected]* <[email protected]>> wrote: Dear all, > > I am thinking what P2P Live Streaming and VoD Service can leverage P2PSIP > RELOAD. According to some research or proposal report, it seems that P2PSIP > RELOAD can be used in P2P-based Tracker and/or chunk description > distribution (chunk discovery) at the full distributed deployment. Both > P2P-based Tracker and chunk description distribution over P2PSIP overlay > were evaluated in performance referred to > draft-chen-ppsp-dht-chunk-discovery-evaluation-00.txt and > draft-hu-ppsp-tracker-dht-performance-comparison-01.txt. The result showed > the performance of DHT-based Tracker and chunk description distribution is > worse, even not acceptable for P2P Live Streaming and VoD Service. > > So can we make such conclusion that P2PSIP RELOAD is not suitable to be > leverage for both P2P Live Streaming and VoD Service in case a full > distributed deployment is not mandatory? What do you think? > > Any comments are welcome. Thanks. > > BR, > Jeffrey > > > > _______________________________________________ > P2PSIP mailing list* > * <[email protected]>*[email protected]* <[email protected]>* > * <https://www.ietf.org/mailman/listinfo/p2psip>* > https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip> > > > _______________________________________________ > P2PSIP mailing list* > * <[email protected]>*[email protected]* <[email protected]>* > * <https://www.ietf.org/mailman/listinfo/p2psip>* > https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip> > > > > _______________________________________________ > P2PSIP mailing list* > **[email protected]* <[email protected]>* > **https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip> > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > _______________________________________________ > P2PSIP mailing list* > **[email protected]* <[email protected]>* > **https://www.ietf.org/mailman/listinfo/p2psip*<https://www.ietf.org/mailman/listinfo/p2psip> > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you have received this email in error please notify the originator of the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
