Another method for doing peer selection utilizing some measure of provisioned bandwidth is the optimization that we used in the P4P trials. In particular, we used peer selection guided by a technique called bandwidth matching. For details, see the section titled "Application with Upload/Download Matching" on Page 4 (labeled page 354) of the Sigcomm 2008 paper: http://ccr.sigcomm.org/online/?q=node/402
Related to Reinaldo's comment about the interaction with localization, we took the approach that the application would first try to maximize its objective (e.g., maximize the total matched bandwidth). Then, we recompute peering guidance to optimize for network efficiency (i.e., minimize ALTO costs) under the constraint that the total matched bandwidth is at least a certain percentage (e.g., 80%) of the optimal value. Put another way, the application sacrifices up to a certain (application-configured) percentage in favor of network efficiency. Nevertheless, in the trials, we did see increased application performance (in addition to increased network efficiency). There are a couple of things to note about the the technique applied here: 1) This optimization was done by the tracker when doing peer selection for newly-joined peers (and peers getting new peer lists from the tracker), and not locally by the peers themselves. 2) Aggregation was applied at the PID level for scalability purposes. The formulation described here can face scalability problems when done swarm- wide without such aggregation, but I mention it here as another possibility for computing peering weights that utilizes bandwidth jointly with localization. -- Richard Alimi Department of Computer Science Yale University On Thursday 18 March 2010 7:19:52 pm Sebastian Kiesel wrote: > On Thu, Mar 18, 2010 at 06:54:13PM -0400, Woundy, Richard wrote: > > How about: > > > > (Probability of picking peer X) := (Prov.BW of peer X) / (Sum prov.BW) > > better. :) though getting BW info for all peers might be unrealistic > > > Or here's a totally different idea. The client states a bandwidth > > floor and the server/service eliminates peers without at least that > > much provisioned bandwidth??? > > The ALTO reqs draft already says: > > 5.3. Performance-related rating criteria > > o The minimum achievable throughput between the resource consumer > and the candidate resource provider, which is considered useful by > the application (only in ALTO queries), or > > o An arbitrary upper bound for the throughput from/to the candidate > resource provider (only in ALTO replies). This may be, but is not > necessarily the provisioned access bandwidth of the candidate > resource provider. > ... > > The ALTO client MUST be aware, that with high probability, the actual > performance values differ significantly from these upper and lower > bounds. In particular, an ALTO client MUST NOT consider the "upper > bound for throughput" parameter as a permission to send data at the > indicated rate without using congestion control mechanisms. > > ... > > Nevertheless, these rating > criteria may provide a useful shortcut for quickly excluding > candidate resource providers from such probing, if it is known in > advance that connectivity is in any case worse than what is > considered the minimum useful value by the respective application. > > > > > > -- Sebastian > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
