On Mon, May 24, 2010 at 11:14:13AM +0200, Enrico Marocco wrote: > To add some information to the discussion, I've uploaded at the > following link some charts showing the observed number of peers a > BitTorrent client got to know while downloading a particular file in > swarms of different size: http://ubiq.tilab.com/~enrico/graphs/ > > While the peers returned by the tracker -- the initial rise in the > graphs -- are important in the first phase of the download, the number > of peers discovered during the entire download period gets often very > close to the size of the swarm.
Isn't this initial phase when joining a swarm the one where ALTO can be most beneficial? IIRC this insight was captured in our charter: "The Working Group will design ... service ... to perform better-than-random *** INITIAL *** peer selection." If we are talking about the application's performance or QoE only: It is no suprise that, if we wait long enough, we can find enough fast neighbors just by gossipping and throughput probing (if fast neighbors actually exist in the swarm). But not trying to optimize the tracker response would mean that we assume, that the tracker is an irrelvant bootstrap helper only, while the "real" neighbor discovery is done by other means, right? If we think of the general case with arbitrary rating criteria that cannot be measured(e.g., monetary cost for data transmission to the candidate peer), all candidate peers should be evaluated by ALTO, no matter whether they were learnt from the tracker or discovered by some other means. Therefore we need an ALTO client in the peer. Nevertheless, the quality (i.e., long-term impact) of the tracker response can be improved by performing an ALTO-guided selection of peers in the tracker. Thanks, Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
