Trying (to get) the peers with the highest actual bandwidth is exactly what P2P protocols do today. The difference is that they take some time to select the better peers through probing, optimistic unchoke, etc.
Therefore I would think and agree that if bandwidth (specially provisioned bandwidth as opposed to actual) is part of the decision process, it can throw localization askew and create a security issue. But this is for P2P swarms client based. For CDN and caches this seems to have its uses but I would think that actual bandwidth (some kind of average) vs. provisioned would be more useful. Thanks, Reinaldo On 3/18/10 2:42 PM, "Sebastian Kiesel" <[email protected]> wrote: > Hi, > > a technical concern regarding the provisioned bandwidth attribute: > > If a P2P app uses this information for a peer selection strategy like > "try the highest bandwidth tier peers first" or "try the highest > bandwidth tier peers with higher probability", and if there is a swarm > with many peers but very few of them are in the highest bandwidth tier, > the user experience of these premium customers might be worse than for a > customer with lower provisioned bandwidth (even if the P2P app uses flow > control and congestion control, the initial syn packets alone could > overwhelm the premium customer's links). > > So we should be very clear what we want to do with this kind of > information in the application. > > > Thinking about this for a while, this problem is not limited to the > provisioned bandwidth. Maybe we need to distinguish between rating > criteria that are commutative (i.e., peer B would be a "good" neighbor > for peer A according to that criterion implies that A would be a "good" > neighbor for B) and those criteria that are not. Using non-commutative > rating criteria might be risky. > > -- 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
