The last P4P field test (from which Comcast has distributed results) compared the two communication models that Spiros describes.
In one case we implemented a "generic" model that applied the ISP guidance to the p2p network with no input from the p2p network. In the other case, the p2p network reported peer distribution and throughput information and used that to produce guidance that was "tuned" to the specifics of the swarm at that point in time. We did not see large improvements in performance. In addition, the first model was significantly easier to implement - there are fewer, simpler messages sent much less often, much less data to compute and store, etc. Importantly, the one-way information flow does not raise privacy concerns. Given this, we (the P4P Working Group) are focusing on the first model for now. That being said, there's certainly a potential for deeper knowledge of the swarm distribution to provide superior guidance, so we would envision this capability as an optional extension that could be utilized when business and technical issues align. The idea of communications between ISPs on this front is very interesting - this is worth pursuing, IMO. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Sebastian Kiesel" <[email protected]> To: "spiros spirou" <[email protected]> Cc: [email protected] Sent: Wednesday, February 25, 2009 8:18:14 AM (GMT-0500) America/New_York Subject: Re: [alto] Comments on requirements draft Spiros, Thank you for your comments on the requirements draft. More sse inline. On Wed, Feb 25, 2009 at 10:02:14AM +0200, Spiros Spirou wrote: > In the current draft, info seems to flow only > from the ALTO service to the P2P system. I feel that there is (or should > be) a reverse flow of info as well: the P2P system informs the provider of > the ALTO service (realistically, a network operator) about P2P system > traffic, so that the operator can do efficient traffic management. The extension you propose here sounds interesting but is rather substantial, so I kindly ask you to give us more information (if you have any), and the other folks here on the list to comment on it: - Are there any field trial or simulation results, which show that this mode of operation can improve the situation? - Would ALTO server operators (i.e., network operators according to your assertion) be willing to receive information from customers (users) via this interface, or will they only trust their own traffic monitoring systems? How big is the risk of this interface being abused? - Who is willing to contribute to this work at this point in time? > Also, to reflect the varying needs of P2P systems and their users, I think > there must be a way for an ALTO client to signal to the ALTO service > preferences regarding rating criteria to be used in calculating > recommendations. (I think this has been already proposed by various people > on the list). Indeed. Some days ago I posted a summary of such rating criteria, which have already been proposed during former discussions, to this mailing list. I am planning to include them in the next version of the requirements draft, so comments are most welcome. That mail was: Message-ID: <[email protected]> Date: Wed, 11 Feb 2009 14:54:57 +0100 Subject: [alto] list of possible attributes (was: Re: differences among applications) > Finally, neighboring domains might agree it makes business sense to > optimize P2P traffic in collaboration. An interface between ALTO services > that would facilitate the exchange of (summarized) topological info to > increase the optimization scope of either, would be helpful in this case. Sure. The fact that this is one part of the big picture has been discussed in the past (see, e.g., the slides from the Dublin meeting) but so far the main focus was on the interface to the clients. Can you propose requirements regarding this interface, or even a solution approach? > Specific changes to the draft that reflect the above are: Thanks. I will consider them when we produce the next revision of the draft. Thanks, Sebastian -- Sebastian Kiesel mailto:[email protected] Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
