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
