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

["Vijay K. Gurbani" <vkg at alcatel-lucent.com>]

I have re-named this thread to track it better and summarize
the discussion.

Stanislav Shalunov wrote:
> The cache discovery portion of ALTO could be equivalent to BEP 22, or it 
> could literally be the mechanism in BEP 22 and that would be quite 
> sufficient for cache discovery.

Stanislav: I think we're making progress.  So, in that spirit,
let's try to flesh this out some more.

Who do you see doing cache discovery?  The ALTO server or the
individual peers?

If we take the view that a cache is a selfless peer who wants
nothing in return, then its discovery is no different than
discovering other peers.  Then this is best relegated as a
normal peer-discovery algorithm/process implemented in any
given P2P overlay.

Now, let's tackle the ALTO server doing cache discovery.  If the
ALTO server can use a standard means to discover a cache, why
can't the peer use the same means?

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.

Then, peers will query the ALTO server using a protocol yet to
be defined (let's refer to this as the TBD protocol.)  This
TBD protocol will have an extension that the peer can use to
provide the ALTO server with some hints (overlay protocol, i.e.,
BitTorrent, eDonkey; hash of the content, etc.)  The TBD
protocol will arrange it such that in a response, the querying
peer is told to contact the cache first.

With some additional work, this extension to the TBD protocol
could be used to also find other resources like VoIP relays,
and it can also be applicable for non-P2P uses like CDN.

Is this an approach that seems feasible?  If so, we can word-
smith something to this effect and add it to the draft
charter.

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