Re: [p2pi] ALTO and caching (Was: Re: Charter and problem statement)

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou at alcatel-lucent.be>]

indeed. you have the traffic-driven discovery (case 1 and 2) and the
control-driven discovery (case 3 and 4). case 3 works w/exploration with
all its drawbacks. 

case 2 in part. breaks the end-to-end communication by requiring
intermediate nodes to inspect traffic (requestor being not aware of the
modification of traffic data path/processing). i strongly oppose to any
protocol development that would rely on such fwd'ing infrastructure
change that are globally detrimental to the Internet accessibility, in
part. those relying on DPI. there should be a clear statement on the
charter that ALTO is not going to develop protocols, e.g. discovery, for
infrastructures sabotaged by DPI.

case 4 has real potential (Server-based cache discovery) note that the
knowledge of cache location may be partial only for the system to work.

-d.

> -----Original Message-----
> From: p2pi-bounces at ietf.org [mailto:p2pi-bounces at ietf.org] On 
> Behalf Of Laird Popkin
> Sent: Wednesday, July 16, 2008 10:23 PM
> To: GURBANI Vijay
> Cc: p2pi at ietf.org
> Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and 
> problem statement)
> 
> There are different entities in different p2p networks that 
> might do cache discovery.
> 
> The current caching vendors provide:
> - In-line 'cache discovery' where the cache is in-line in 
> traffic, caching data and responding to requests rather than 
> passing the requests for cached data on to other peers. This 
> is fragile and doesn't scale well.
> - DPI-based 'cache discovery', where a DPI box inspects the 
> p2p traffic and tells the p2p cache server about p2p 
> tranfers, which the cache server can join into. This is also 
> fragile, involving protocol reverse engineering.
> - Client-based cache discovery, where each p2p client on each 
> download start would perform (theoretically) one cache check 
> for each cache vendor, and use whatever comes back. This is 
> complex and inefficient.
> - Server-based cache discovery, where each p2p network knows 
> where p2p cache servers are and tells appropriate peers to 
> connect to the caches. This is the most efficient approach, 
> but requires ISPs to inform p2p networks of cache locations 
> and rules (e.g. IP prefixes) for assigning users to caches, 
> or equivalent lookups.
> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "Vijay K. Gurbani" <vkg at alcatel-lucent.com>
> To: "Stanislav Shalunov" <shalunov at shlang.com>
> Cc: p2pi at ietf.org
> Sent: Wednesday, July 16, 2008 4:08:56 PM (GMT-0500) America/New_York
> Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and 
> problem statement)
> 
> Stanislav Shalunov wrote:
> > On Jul 16, 2008, at 8:13 AM, Vijay K. Gurbani wrote:
> >> Who do you see doing cache discovery?  The ALTO server or the
> >> individual peers?
> > 
> > Peers mainly.  The ALTO server might use these same means as a 
> > convenience, but one can think of it as being configured with this 
> > information.
> 
> OK; good.  So we have peers that mainly perform cache discovery
> using some protocol (more on this below.)
> 
> >> I believe that if cache discovery is moved to the realm of
> >> the ALTO server, it becomes more of cache "dissemination" problem
> >> than of cache "discovery."  In other words, the ALTO server
> >> will be pre-configured by the ISP  -- or if it is not operated by
> >> the ISP, will use other means -- to maintain a set of known caches.
> >> It has been suggested that caches "register" to the ALTO server.
> >> I think that this is probably not a good idea for a variety of
> >> reasons.
> > 
> > I don't see why we need to standardize how ALTO servers are 
> configured 
> > in this regard.  
> 
> You misunderstood.  I was not saying that we standardize how ALTO
> servers are configured (we should not go down that path, obviously.)
> The point of my paragraph above was to determine if the ALTO server
> is the only entity that does cache discovery, do we need to
> specify a protocol at all?
> 
> So, it looks like the following statements apply (for sake of
> sanity, I will take a leap of faith and assume that we have an
> actual ALTO server instead of representing it a URL of a BGP dump):
> 
> Discovering caches and other resources:
> 
>    1) Peers may discover caches using a protocol X. The protocol
>     X may be as simple as using well known DNS techniques to
>     bootstrap the discovery process (i.e., something akin to
>     DNS-SD, BEP-22, etc.)
> 
>    2) The ALTO server may be asked by the peers to discover caches
>     using certain extensions to the ALTO protocol Y (Note: Y != X).
>     When so asked, the ALTO server can use protocol X to discover
>     those caches on behalf of the peers, and using additional
>     information provided by the peer.
> 
>    3) The ALTO server may be asked by applications to discover
>     other resources using certain extensions to the ALTO protocol Y.
>     When so asked, the ALTO server can use protocol X to discover
>     such resources on behalf of the applications, and using additional
>     information provided by the application.
> 
> Yes?
> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
> _______________________________________________
> 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