In case anyone's curious, there's more info on P4P at http://cs-www.cs.yale.edu/homes/yong/p4p/index.html. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "michael dillon" <michael.dillon@bt.com> To: nanog@nanog.org Sent: Wednesday, April 23, 2008 6:40:11 PM (GMT-0500) America/New_York Subject: Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]
However, as your chunk scheduling becomes more effective, it usually becomes more expensive. At some point, its increasing complexity will reverse the trend and start slowing down copies, as real-world clients begin to block making chunk requests waiting for CPU to make scheduling decisions.
This is not a bad thing. The intent is to optimize the whole system, not provide the fastest copies. Those who promote QoS often talk of some kind of scavenger level of service that sweeps up any available bandwidth after all the important users have gotten their fill. I see this type of P2P system in a similar light, i.e. it allows the ISP to allow as much bandwidth use as is economically feasible and block the rest. Since the end user ultimately relies on an ISP having a stable network that functions in the long term (not drives the ISP to bankruptcy) this seems to be a reasonable tradeoff.
As seems to be a trend, Michael appears to be fixated on a specific implementation, and may end up driving many observers into thinking this idea is annoying :) However, there is a mathematical basis for including topology (and other nontraditional) information in scheduling decisions.
There is also precedent for this in manufacturing scheduling where you optimize your total systems by identifying the prime bottleneck and carefully managing that single point in the chain of operations. I'm not hung up on a specific implementation, just trying to present a concrete example that could be a starting point. And until today, I knew nothing about the P4P effort which seems to be working in the same direction. --Michael Dillon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog