Changes between Version 4 and Version 5 of GENIEducation/SampleAssignments/CCNAssignment/ForInstructors

06/03/13 14:42:13 (6 years ago)



  • GENIEducation/SampleAssignments/CCNAssignment/ForInstructors

    v4 v5  
    163163  '''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.
    175  * Answers can be found [ Here]
     165  - '''Task 1.3: Explore traffic patterns''' [[BR]]
     166  ''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]]
     167  Instrumentize your experiment using GEMINI following the instructions here: [ GENIDesktop Tutorial]. [[BR]]
     168  Log into the host collaborator1 and use the Atmos client to fetch data from 1902/01/28 to 1902/02/03. Look at the GEMINI data usage, and observe that data is pulled from both datasource1 and datasource2, through router to researcher1 and ultimately to collaborator1. Record or remember the data rates and volumes from this transaction. On the GEMINI web interface (GENIDesktop), show real-time graphs from datasource1, datasource2, router, researcher1 and collaborator1, record the throughput numbers or screenshot the graphs. [[BR]]
     169  - '''Question 1.3 A:''' [[BR]]
     170  Log into ''collaborator2'' and fetch the same dates. Which hosts transfer data? why?
     171  - '''Question 1.3 B''' [[BR]]
     172  Now fetch 1902/01/25 to 1902/01/31 from ''researcher2''. How does this transfer differ from the previous two? why?
     174 - '''3.2 Choosing Content Names''' [[BR]]
     175 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]]
     176 The ''Atmos'' package uses content names in the namespace ''/ndn/'' 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/''
     177  - '''Task 2.1: Granularity of naming''' [[BR]]
     178  ''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]]
     179  Create an experimental network using the ''naming.rspec'' 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]]
     180  Fetch the Atmos source from 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]]
     181  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 '''' and '''', respectively. On each of these hosts run the command ''ccninitkeystore'' and start the Atmos server with the following commands:
     183cd /tmp
     184$HOME/ccnx-atmos/server $DATAFILE
     186  Substitute ''$HOME/ccnx-atmos'' for your actual Atmos build directory, and $''DATAFILE'' for the appropriate filename as described above. [[BR]]
     187  On the client host you chose, run ''./'' from the data directory and select a few dates from January and February of 1902 for date ranges. Make note of what interests are received at the server, and how long the transfers take. [[BR]]
     188  Change the client and server programs to use this URI, restricting CCNx transfers to a granularity of one month, but preserving the ability of users to retrieve at one day granularity: ''/ndn/<year>/<month>''[[BR]]
     189  '''Implementation Hints:''' It is important understand how '''' uses NetCDF commands to extract relevant dimensions in the data files. The client ('''') breaks up a user’s request into a collection of URIs (one for each day) and fetches them sequentially. For each URI, generates a list of timestamps (a floating point number indicating the number of days elapsed since January 1, 1901). From the NetCDF data files, extracts the fields that lie within these timestamps. The server side changes are minimal. Once a month’s granularity of data is received at the client side, it should be filtered to match the specific days requested by the user. [[BR]]
     190  Retrieve a variety of dates in the January to February 1902 date range, and note again what interests are received at the server and how long the transfers take. [[BR]]
     191  - '''Question 2.1 A''' [[BR]]
     192  What general difference do you see in network behavior between these solutions?
     193  - '''Question 2.1 B''' [[BR]]
     194  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]]
     196 - '''3.3 Exploring the Impact of Caching''' [[BR]]
     197 For this exercise you will manipulate various caching parameters for the ccnd daemon and observe the effects on network efficiency. [[BR]]
     198 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]]
     199 Caching behavior can be controlled by the client, the server, or the individual ccnd nodes between the two. Servers can optionally specify the recommended cache lifetime of data they generate, clients can optionally request that their data is fetched from the server itself (bypassing caching), and ccnd nodes can define their default and maximum cache lifetimes. Caches may also be affected by the available cache space and volume of interests or data items passing through the cache. [[BR]]
     200  - ''' Task 3.1: Opportunistic caching''' [[BR]]
     201  ''This task will demonstrate the benefit of opportunistic caching for static data used repeatedly.'' [[BR]]
     202  Create a GENI slice using ''cache.rspec'' from [ 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]]
     203  - '''Question 3.1 A''': [[BR]]
     204  From the host consumer run ''/opt/ccnx-atmos/'' 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]]
     206== 4. Other Projects ==
     207The following are ideas for deeper projects into named data/content-centric net- working or the implementation embodied in CCNx.
     208 - Design and implement a cache coherence or cache management protocol for content subscribers or content providers to communicate with intermediate nodes to improve caching strategies in the presence of data with dissimilar caching requirements.
     209 - Develop an application-specific caching mechanism for some data type (perhaps NetCDF) and deploy it in CCNx.
     210 - Design and implement a protocol for ccnd to communicate directly with other ccnd instances via raw Ethernet frames without IP, ARP, or the rest of the TCP/IP stack.
     212== 5. Hints ==
     213These hints and answers to common questions may help you debug problems you encounter while performing the exercises in this assignment.
     214 - Remember that you must run ''ccninitkeystore'' before invoking any commands that use ccnd. If CCNx commands don’t seem to be “doing anything”, make sure you have the file ''.ccnx/.ccnx'' keystore in your home directory. If it is not present, you have forgotten to initialize the keystore!
     215 - If you are told that CCNx-related commands such as ''ccndc'' are not found, make sure that ''/opt/ccnx-0.6.1/bin'' is in your shell’s path.
     216 - The status of ccnd can be queried either by logging into a host and running ''ccndstatus'', or by loading the web page served by ccnd on port 9695. For example, if your ''researcher2'' node is on '''' and you want to query its forwarding table, you can point your web browser at ''''.
     217 - If the GENI Desktop portal shows a blank page, and you are running the Chrome browser, click the shield icon at the right of the URL bar and select “Load Anyway”.