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

From: Laird Popkin <[email-masked]>
Date: Wed, 16 Jul 2008 16:22:46 -0400 (EDT)

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" <[email-masked]>
To: "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
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@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Jul 2008 15:37:22 -0500

> There are different entities in different p2p networks that might do 

Laird: Thank you for this taxonomy.  It is good.  More inline.

> 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

Sure; this is what I call the "Squid" model.  Besides the dis-
advantages you mention above, content expiry (or staleness)
is another disadvantage.

> - 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.

Sure.  Agreed.

> - 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.

Yes.

> - 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.

This is essentially what people seem to be interested in.

Thanks,

- vijay

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 17 Jul 2008 09:13:16 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Laird Popkin
> Sent: Wednesday, July 16, 2008 10:23 PM
> To: GURBANI Vijay
> Cc: [email-masked]
> - 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.
> 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.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 17 Jul 2008 13:39:06 -0500

> knowledge of cache location may be partial only for the system to work.

Dimitri: OK, thanks.  The general consensus appears to that server-
based cache discovery is probably the best way forward (again,
taking a leap of faith and assume that we have an actual ALTO
server instead of representing it a URL of a BGP dump.)

We have allocated time to Reinaldo Penno for presentation on
the caching discussion, including summarizing the consensus
on the discussions we have had on the mailing list over the last
couple of days.  The updated agenda is available on the
IETF website (please see
http://www.ietf.org/proceedings/08jul/agenda/alto.html).

Thank you all for a good discussion on this.

Ciao.

- vijay

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 17 Jul 2008 23:28:11 -0400

Here are a few more thoughts on P2P caching.

>case 3 [Client-based cache discovery] works w/exploration with all its
drawbacks.

Here's a thought: could it be possible for the client to learn that
content may be cached (or is cachable) by an entity (e.g. his ISP) via
content metadata? Then the client could learn the actual P2P cache
location using an ALTO request, say.

>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.

Personally, I would agree that ALTO should develop P2P cache discovery
mechanisms that do NOT rely on DPI diversion of traffic. It would be
much more elegant for a peer and/or tracker to consciously choose to
leverage a P2P cache, than for a middlebox to make that choice.

(Offline, some folks have pointed out that the DPI could divert P2P
traffic on a customer opt-in basis. However, it would seem to be very
difficult for the customer to opt-in for diversion for some content
downloads, but not for others, but I digress.)

But I feel obliged to note that the use of DPI diversion for P2P traffic
is common in vendor pitches for P2P caching products, and I suspect that
a number of ISPs (emphatically NOT Comcast) have already deployed P2P
caching in conjunction with DPI. And of course the core reason is that
there is little to no support for cache discovery in existing clients
and trackers -- which hopefully will change soon. I thought I should
point this out before we agree to "outlaw" the DPI approach.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
PAPADIMITRIOU Dimitri
Sent: Thursday, July 17, 2008 3:13 AM
To: Laird Popkin; GURBANI Vijay
Cc: [email-masked]
Subject: Re: [p2pi] ALTO and caching (Was: Re: Charter and problem
statement)

-d.