I agree. Here's a slightly different example. The common tier for ISP A may have provisioned bandwidth of 12 Mbps, and 10 Mbps for ISP B. Assuming that an application doesn't need 11 Mbps, it may make more sense for the app to pick an ISP A client 12 times out of 22 (55%), and an ISP B client 10 times out of 22 (45%), rather than an ISP A client 100% of the time.
-- Rich -----Original Message----- From: Sebastian Kiesel [mailto:[email protected]] Sent: Thursday, March 18, 2010 5:42 PM To: Woundy, Richard Cc: [email protected] Subject: Re: [alto] Comments on provisioned bandwidth and ALTO 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
