Context Navigation

ForInstructors

Timestamp:: 06/03/13 14:49:15 (11 years ago)
Author:: shuang@bbn.com
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

GENIEducation/SampleAssignments/CCNAssignment/ForInstructors

-                      v5
+                      v6
   What intents show up at datasource1 for this request? (Use the timestamps in the server log to correlate requests with specific intents.) Will you observe unique or duplicate intents when both researcher1 and researcher2 fetch the same data at precisely the same time? Why? [[BR]]
   '''Answer:''' I see unique intents when both researcher1 and researcher2 fetch the same data at the same time. ccdn is able to intelligently identify duplicated intent and effectively filter it during propagation.
   - '''Task 1.3: Explore traffic patterns''' [[BR]]
   ''For this task, you will start network monitoring services on your slice and observe the data traffic passing between hosts as you fetch various content.'' [[BR]]
 …
   Now fetch 1902/01/25 to 1902/01/31 from ''researcher2''. How does this transfer differ from the previous two? why?
  - '''3.2 Choosing Content Names''' [[BR]]
+ - '''3.2 Choosing Content Names''' [[BR]] -- Files to download: [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/naming.rspec naming.rspec], [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/ccnx-atmos.tar.gz ccnx-atmos.tar.gz]
  This exercise will demonstrate the importance of naming in named data networking. As the term suggests, and as you saw in Task 1.1, routing in named data networking is performed based on content names. This means that content naming has a large impact on how consumers fetch the data they require, and naming structure can heavily influence how simple and efficient data requests may be. [[BR]]
  The ''Atmos'' package uses content names in the namespace ''/ndn/colostate.edu/netsec'' to serve NetCDF data. The data is sliced by time, with the suffix pr_<year>/<month>/<day>/00 added to represent data for the specified date. Thus, clients can request precipitation data for a given day in history, or a range of days, by issuing an interest for the dates in question. The complete path for data relating to January 3, 1902 would be: ''/ndn/colostate.edu/netsec/pr_1902/01/03/00''
   - '''Task 2.1: Granularity of naming''' [[BR]]
   ''This task will require you to change granularity of content names used by the Atmos client and server for different use cases, and measure the resulting traffic changes.'' [[BR]]
   Create an experimental network using the ''naming.rspec'' RSpec [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/naming.rspec HERE]. This RSpec creates a network of the same topology as the network used in Exercise 3.1, but does not start or install the Atmos server or client. You will be modifying and installing this software yourself. [[BR]]
+  Create an experimental network using the ''naming.rspec'' RSpec [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/naming.rspec HERE] (Note: this experiment does not require using GEMINI to monitor the network). This RSpec creates a network of the same topology as the network used in Exercise 3.1, but does not start or install the Atmos server or client. You will be modifying and installing this software yourself. [[BR]]
   Fetch the Atmos source from http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/ccnx-atmos.tar.gz. You may fetch it directly to the testbed nodes you will be using, or to a local machine, as you prefer. You will have to copy the source code to the GENI nodes to build and run it in your experiment. [[BR]]
   Build the Atmos source on hosts ''datasource1'' and ''datasource2'', as well as a collaborator or researcher node of your choice by entering the source directory and running ''make''. On ''datasource1'' and ''datasource2'', you will find a NetCDF data file in /tmp, named ''pr_19020101_060000.nc'' and ''pr_19020201_060000.nc'', respectively. On each of these hosts run the command ''ccninitkeystore'' and start the Atmos server with the following commands:
 …
   Which URI scheme is more efficient in time and network resources if the user only wants a few days of data? What if the user wants a full calendar month of data? [[BR]]
  - '''3.3 Exploring the Impact of Caching''' [[BR]]
+ - '''3.3 Exploring the Impact of Caching''' [[BR]] -- Files to download: [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/cache.rspec cache.rspec]
  For this exercise you will manipulate various caching parameters for the ccnd daemon and observe the effects on network efficiency. [[BR]]
  A property of named data networking is that multiple requests for the same names may return the same data. This allows intermediate nodes to cache data from one request for a given name and return it for future requests of the same name, from the same client or even a different client. When multiple clients located near each other but far from the server in the network want the same data, a node near the clients may be able to service some clients without contacting the server. [[BR]]
 …
   - ''' Task 3.1: Opportunistic caching''' [[BR]]
   ''This task will demonstrate the benefit of opportunistic caching for static data used repeatedly.'' [[BR]]
   Create a GENI slice using ''cache.rspec'' from [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/cache.rspec Here]. This slice has only two hosts, a data source and a data consumer. The data source serves historical precipitation data using the Atmos server, which is static information. It has a long cache timeout for this reason — five minutes. The data consumer uses a shorter cache timeout of 60 seconds, and the link between the two emulates a moderate consumer broadband link. [[BR]]
+  Create a GENI slice using ''cache.rspec'' from [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/cache.rspec Here] (Note: this experiment does not require using GEMINI to monitor the network). This slice has only two hosts, a data source and a data consumer. The data source serves historical precipitation data using the Atmos server, which is static information. It has a long cache timeout for this reason — five minutes. The data consumer uses a shorter cache timeout of 60 seconds, and the link between the two emulates a moderate consumer broadband link. [[BR]]
   - '''Question 3.1 A''': [[BR]]
   From the host consumer run ''/opt/ccnx-atmos/client.py'' to fetch data from 1902/01/21 through 1902/01/24, and time the total transaction. Within 60 seconds, fetch the same data again, and time it. After 60 seconds (but before 300 seconds have passed), fetch it a third time, and time that. What is the benefit of local caching (the second fetch)? Is there perceptible benefit from server-side caching (the third fetch) when data takes some time to generate? [[BR]]