Re: [p2pi] Charter and problem statement

["Stas Khirman" <stas at khirman.com>]

I will not be so optimistic.... 

Just a few numbers to consider:
- From time of system deployment (2003?), Comcast sold 6 billions VoDs
views.
- iTune sold only sold 125 million TV shows and 7 million movies since its
launch (2005?)
- Mininova ( most popular BT portal) facilitated 3.3 billion torrents
downloads ( about 80% - movies and TV shows) in 12 months (May 2007-May
2008)
- ThePirateBay and IsoHunt have in total more daily visitors then Mininova
(and so - facilitated downloads)

> -----Original Message-----
> From: Laird Popkin [mailto:laird at pando.com]
> Sent: Tuesday, July 22, 2008 8:52 AM
> To: Richard Woundy
> Cc: p2pi at ietf.org; Stas Khirman
> Subject: Re: [p2pi] Charter and problem statement
> 
> This is a good point. There are estimates that "legit" p2p content could
> rapidly grow to be much larger than "pirate" p2p content. For example, if
> every home on broadband watched one HD TV show a day, that would be more
> data than the internet moves now (or can move from any central location).
> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "Richard Woundy" <Richard_Woundy at cable.comcast.com>
> To: "Stas Khirman" <stas at khirman.com>, "Laird Popkin" <laird at pando.com>
> Cc: p2pi at ietf.org
> Sent: Saturday, July 19, 2008 12:38:31 PM (GMT-0500) America/New_York
> Subject: RE: [p2pi] Charter and problem statement
> 
> >In this use case, inclusion of content id into ALTO request makes no
> sense at all but opens a Pandora box of potential liabilities. Making it
> optional with end-user manual configuration will not help - even if small
> part of users keep it ON, it will create a sufficient reason for DMCA-like
> request to filter P2P content.
> 
> Maybe the client could determine by out-of-band means (e.g. metadata)
> whether it makes sense to send the content ID in an ALTO request.
> 
> There is an underlying assumption here that every P2P user is going to
> request at least some illicit content (copyright infringing or kiddie
> porn). What if P2P was primarily used for "legitimate" content
> distribution? How would that assumption influence our requirements?
> 
> At the same time, I would caution against assuming that the lack of
> content identification in any ALTO request implies that the user is
> attempting something illegal. There are obviously many privacy concerns
> besides trying to evade one's legal system...
> 
> -- Rich
> 
> ________________________________
> 
> From: p2pi-bounces at ietf.org on behalf of Stas Khirman
> Sent: Sat 7/19/2008 1:13 AM
> To: 'Laird Popkin'; Woundy, Richard
> Cc: p2pi at ietf.org
> Subject: Re: [p2pi] Charter and problem statement
> 
> 
> 
> > -----Original Message-----
> > From: Laird Popkin [mailto:laird at pando.com]
> > Sent: Friday, July 18, 2008 3:57 AM
> > To: Richard Woundy
> > Cc: p2pi at ietf.org; Stas Khirman
> > Subject: Re: [p2pi] Charter and problem statement
> >
> > I agree  with Richard - as long as content ID's are optional and
> > abstracted (e.g. content ID's are not Torrent ID's) I don't think
> there's
> > a privacy issue.
> 
> [Stas Khirman]
> 
> Laird and Richard,
> 
> Thank you for clarifying this issue - I convinced that content id does not
> create additional problems in use case when ISP is using cache servers.
> Indeed, if any kind of caching implemented on ISP level, they already have
> privacy/DMCA questions resolved somehow. It also true for use case of P2P
> CDN that use P4P architecture (ALTO server polled by pTracker ). In those
> use cases, including content id in ALTO request makes no harm, and can be
> quite useful for cache location and [probably] other goals (differentiated
> QoS ?)
> 
> However, I still worry about use case that seems to be more "popular" ( in
> term on number of users) : due variety of [legal] reasons,  ISP does not
> install caching at all, but want to use ALTO-powered transport
> optimization
> for BitTorrent, eDonkey and similar P2P traffic (assuming that major P2P
> clients adopted ALTO).
> 
> In this use case, inclusion of content id into ALTO request makes no sense
> at all but opens a Pandora box of potential liabilities. Making it
> optional
> with end-user manual configuration will not help - even if small part of
> users keep it ON, it will create a sufficient reason for DMCA-like request
> to filter P2P content. And it is not just hypothetical speculation - see
> for
> example http://yro.slashdot.org/article.pl?sid=07/07/05/1512247&from=rss
> http://torrentfreak.com/isps-should-block-bittorrent-and-tpb-071226/ .
> 
> Probably, "optionally" can be achieved if during ALTO server discovery
> stage
> ( DNS?) client receives some kind of "configuration" flag and will be
> mandated NOT TO send content id. Will it pass legal scrutiny? Will be ALTO
> server used by DMCA/IFPA as a proof of ISP ability to filter P2P ? I have
> no
> idea, but assume that the better "DMCA-proof" solution is to separate
> "content-sensitive" functionalities (like cache discovery) from "content
> agnostic" ones.
> 
> 
> >
> > There are a number of use cases where metadata related to the content
> > could be useful in allowing the ALTO server to make decisions. For
> example,
> > an ISP might want to implement policies in their ALTO server such as:
> >
> > - Don't cache consumer generated content (requires being able to
> > differentiate between CGC and commercial content).
> > - Provide different guidance to different applications (requires
> knowledge
> > of p2p application).
> > - Provide guidance based on distribution of that content (requires ID of
> > that specific content).
> >
> > It's a good point that once content is cached the ISP knows a lot about
> > the content and its distribution. In particular, since it's
> participating
> > in the p2p network it knows the IP addresses of people exchanging the
> > content, whatever metadata is exposed about the content in the protocol
> > (e.g. size, number of files, names). And for p2p networks that don't
> > secure content on caches (Pando does, but some others do not) the ISP
> has
> > the content on the cache server and can inspect it directly. But this is
> > (IMO, IANAL) similar to the case of an HTTP cache or an email server -
> the
> > ISP is providing a service, and privacy of use of that service is
> > protected by policy, not by technology.
> >
> > Given all of that, ALTO can certainly be applied to content that isn't
> > cached, and it should preserve privacy for that content. :-)
> >
> > - Laird Popkin, CTO, Pando Networks
> >   mobile: 646/465-0570
> >
> > ----- Original Message -----
> > From: "Richard Woundy" <Richard_Woundy at cable.comcast.com>
> > To: "Stas Khirman" <stas at khirman.com>, "Laird Popkin" <laird at pando.com>
> > Cc: p2pi at ietf.org
> > Sent: Thursday, July 17, 2008 10:34:48 PM (GMT-0500) America/New_York
> > Subject: RE: [p2pi] Charter and problem statement
> >
> > >It seems that we agree on the key point - content identity in ALTO
> > ["peer
> > selection"] request will be harmful.
> >
> > >It will be very important to get confirmation/rejection of this
> > assumption
> > from ISP's representatives.
> >
> > I've been thinking about this since yesterday, and I'm not really sure I
> > agree with this statement.
> >
> > I definitely understand that there would likely be privacy concerns if
> > ALTO mandated content identification in its messages. Content identities
> > should be an optional parameter in the ALTO message exchange (if we can
> > agree that it should be kept at all).
> >
> > But I would think that having the content identity could help an ALTO
> > server make a better recommendation, at least for P2P caches.
> >
> > Consider the case when the ISP is operating an ALTO server as well as a
> > P2P cache. If there isn't an issue of violating customer privacy, why
> > would it be undesirable to reveal the content identity to the ALTO
> > server, when it is necessary to reveal the content identity to the P2P
> > caching server?
> >
> > In fact, the P2P caching server knows potentially more valuable
> > information than the content identity. ALTO would only know about
> > metadata for content, whereas the P2P cache would have a copy of the
> > actual content.
> >
> > To illustrate, suppose that some content's metadata (e.g. torrent)
> > indicates that the file is "Spiderman" and not much more. It is possible
> > that the file represents a DVD rip of a Spiderman movie. It is equally
> > possible that the file represents a digital home video of someone's
> > child wearing a Spiderman costume for Halloween. Examining the actual
> > content (as stored on the P2P cache) would help determine which scenario
> > is true.
> >
> > -- Rich
> >
> > -----Original Message-----
> > From: p2pi-bounces at ietf.org [mailto:p2pi-bounces at ietf.org] On Behalf Of
> > Stas Khirman
> > Sent: Wednesday, July 16, 2008 5:55 PM
> > To: 'Laird Popkin'
> > Cc: p2pi at ietf.org
> > Subject: Re: [p2pi] Charter and problem statement
> >
> > > -----Original Message-----
> > > From: Laird Popkin [mailto:laird at pando.com]
> > > Sent: Wednesday, July 16, 2008 11:15 AM
> > >
> > > I agree that keeping content identity out of cache location is a good
> > idea.
> >
> > [Stas Khirman]
> > Laird,
> >
> > It seems that we agree on the key point - content identity in ALTO
> > ["peer
> > selection"] request will be harmful.
> >
> > It will be very important to get confirmation/rejection of this
> > assumption
> > from ISP's representatives.
> >
> >
> > > That being said, cache location doesn't need to be content-specific,
> > > because one the p2p client connects to the caches, the caches can
> > > determine what they do on a content-specific basis. So ALTO could (for
> > > example) decide which cache servers to send to a user based on the
> > user's
> > > network location and protocol (e.g. Pando caches might run on
> > different
> > > servers from Kontiki caches or HTTP caches, etc.). But as long as ALTO
> > can
> > > return multiple cache servers (i.e. pools) the cache servers can
> > manage
> > > whether to cache specific content, or where to assign it,
> > transparently to
> > > ALTO, without ALTO having to know (for cache location) what content is
> > > assigned where. This is good for the caches, as it gives them maximum
> > > flexibility, without having to implement a complex state-change
> > mechanism
> > > between the cache servers and the ALTO server.
> > >
> > [Stas Khirman]
> > Lets review a few usage cases to decide if ALTO can locate optimal cache
> > without content identity.
> >
> > 1.) Cache implemented as a single virtual peer or as a set of peers with
> > the
> > same cached content. Certainly, no content knowledge needed to locate a
> > most
> > appropriate server. However, such architecture doesn't scale.
> >
> > 2.) Cache implemented as distributed set of servers where given content
> > may
> > be located in some subset of nodes. If ALTO return [ordered] list of all
> > known servers, it will be up to client application to poll them to
> > discover
> > which one has appropriate content. Sometimes it will work, but with
> > large
> > list it takes significant time, especially harmful for applications that
> > uses cache for bootstrapped playback.
> >
> > 3.) Cache implemented in master-slave hierarchy. ALTO returns a pointer
> > to a
> > master cache (cache director). Upon client connection, master redirects
> > it
> > to a slave cache that has appropriate content. However, "master" do not
> > have
> > enough knowledge to pick "ALTO optimized" slave server from set of
> > appropriate ( I assume that popular content may be presented in multiple
> > cache locations). Master can resolve this issue with a second ALTO
> > lookup,
> > but it not different from separated "discovery" and "optimization" calls
> > as
> > I suggested.
> >
> > 4.) Cache service implemented by third party CDN ( I assume you referred
> > to
> > this specific case).  In this case decision what cache to be used is
> > under
> > control on another party (CDN owner) who may have "optimization" policy
> > quite different then originating ISP (those diminishing value of ISP-own
> > ALTO service). Probably it is extreme speculation, but in theory, Tier-1
> > ISP
> > operated CDN may use "selection" policy that increase its own profit,
> > but
> > not decrease cost of originating ISP.
> >
> >
> >
> >
> > _______________________________________________
> > p2pi mailing list
> > p2pi at ietf.org
> > https://www.ietf.org/mailman/listinfo/p2pi
> 
> _______________________________________________
> p2pi mailing list
> p2pi at ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
> 


_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi