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]> 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]> 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]> 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]> 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] >>> 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
