cnap

[Kobus Van der Merwe <kobus@research.att.com>]

Some comments on the breakdown of functionality and different
protocols involved with CI as described in section 2 of
draft-cain-cdi-cnap-00.txt.

For pull-CNs (i.e. CNs that populate surrogates on-demand)
that use a DNS based redirection system I think the breakdown
holds as follows:
- step 1 (section 2.1) says this is where you (other CN) can get the
content (when you need it) and please update your redirection
system to reflect that
- with advertisements in step 2 the CN says, yes I still know
about this content (identified and aggregated by CNAME) and this
is what the weather looks like on my CN
- in step 3 a meta update protocol can be used to invalidate
any particular pieces of content
Note that for this scenario step 3 does not really impact
steps 1 and 2 because 1 and 2 operate at a different level of
granularity. (as per section 2.4)

This does not hold however for push CN (i.e. CNs that (has to)
pre-populate surrogates with content before it can be served).
Several streaming CNs (still) operate in this fashion and unless
such CNs are considered out of scope I think it is an important
real world example. Firstly, in this setup DNS based redirection
will not be adequate because a redirection decision has to be
made based on whether the specific requested content is currently
available in a CN. So in this case  the steps will go as follows:
- in step 1 distribution of specific content to CNs will be requested
(i.e. this is where you can get it and please get it right now)
- confirmation that this content is now available in a particular CN
either as a result of step 1 or through the CNAP protocol in
step 2 will allow request for this content to be directed to the
CNs in question
- invalidating (or withdrawing) content through a meta update
protocol can happen as before. However in this case it will
have to trigger action in step 2 as this content is no longer
available in the CN. So basically in this scenario it
is not clear that CNAP content advertisements will be long-lived
as per section 2.4 and seems to suggest a tighter coupling between
the different steps/protocols.

(I note that the actual protocol description in section 3 seems
to accommodate both scenarios.)

Kobus