Thanks to Enrico and Nicholas for providing additional background and explanations.
The key point of disagreement seems to be that adding a content protection requirement to ALTO would "hugely complicate and compromise the design of ALTO." I'm not an expert in such matters, have very limited exposure to the area, and can't help but wonder if that is, in fact, correct. Was there a serious investigation or did someone simply do a back-of-the-envelope analysis. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nicholas Weaver Sent: Thursday, April 30, 2009 9:55 AM To: Enrico Marocco Cc: Paul Jessop; [email protected]; Nicholas Weaver; alto; DePriest, Greg (NBC Universal) Subject: [alto] The origins of the piracy debate... On private discussion with Greg DePriest, I think I understand his viewpoint, but also that the viewpoint arrises from a misconception. ALTO will basically operate in one of the following manners (exact mechanism is subject for debate, but this is the general concept): 1) Client queries "Who should I talk to who's participating in identifier ID" (Q? ID) 2) Client queries "Who among this list of participants is best to talk to" (Q? IP-LIST) 3) Client queries "For ID Q, who among this list of participants for identtifier ID" (Q? ID, IP-LIST) And there are significant advantages to #1 or #3. Greg has been operating under the assumption that it is either 1 or 3, and that ID must be stable, meaningful, and reasonably long lived. Which is the case for IDs (hashes) in P2P protocols. If that is the case, then his argument is "At least allow us to play Whak-a-mole by saying 'these hashes are bad'". Which does work to some degree. And if ALTO was a distributed caching or distributed search protocol, I'd agree with him, 100%. For in those things, ID generally has to relate to the content (its a hash, and its long-lived), so with an automated system, you can play automatic DMCA Whak-a-mole and have an effect. However, I believe (and I think there is a consensus) that IDs are opaque data to ALTO, simply a blob of bits provided by the P2P protocol, and are probably best specified as UUIDs. And ALTO's IDs only need to be for a very short time, sufficient to rebalance the P2P network. Thus if ALTO provides a significant performance gain for P2P (as opposed to an aggregate cost savings, where I believe the benefits lie), a pirate data source can simply churn IDs very quickly: "For the next 20 seconds, all peers should reoptimize using this NONCE". And there are reasons for such reoptimizations on purely legitimate P2P, (eg, churning ID's allows you to "reoptimize now" and avoid problems with stale data in ALTO) so you can't block that behavior. Thus since IDs don't have to be long lived for this use, nor related to the file content, you can't play whak-a-mole, and building that facility into Alto's infrastructure doesn't help content providers vs the pirates but would hugely complicate and compromise the design of ALTO. Since an "exclude these" model wouldn't work due to churn, the only way ALTO could provide content protection is an "include only" rule: only identifiers which are specifically ADDED by a "trusted" source are supported, and I believe that would be a huge compromise in ALTO's usability (why don't these trusted sources just pay for Akamai and not use P2P?), and even that might not work as pirates could optimize on "lightly used but allowed" identifiers and just ignore the false matches. This is the best reason why "Content protection is not in the ALTO charter": ALTO, by its limited nature and viewpoint, can't provide content protection, and attempting to provide such functionality anyway would significantly compromise alto's design. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
