Changes between Version 7 and Version 8 of GENIEducation/SampleAssignments/CCNAssignment/ForInstructors


Ignore:
Timestamp:
06/03/13 15:22:53 (11 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIEducation/SampleAssignments/CCNAssignment/ForInstructors

    v7 v8  
    2828  ''In this task, you will observe the effects of the missing static routes, and restore them.'' [[BR]]
    2929  Log into the host ''researcher1''. Run the command ''ccninitkeystore''. Issue the command ''ccndstatus'' to print the status of the ccnd daemon on the local host. Note the number of content items stored on this host (which should be zero, if you have not yet fetched any content) and the number of interests accepted (under “Interest totals”).[[BR]]
    30   Output for ''ccndstatus'':
     30   Output for ''ccndstatus'':
    3131{{{
    3232[shufeng@researcher1 ~]$ ccndstatus
     
    5555 ccnx:/%C1.M.S.localhost face: 0 flags: 0x23 expires: 2147478157
    5656}}}
    57   On ''researcher1'', issue a request for precipitation data from 1902/01/01 through 1902/01/02. To do this, use the Atmos tools by invoking:
     57   On ''researcher1'', issue a request for precipitation data from 1902/01/01 through 1902/01/02. To do this, use the Atmos tools by invoking:
    5858{{{
    5959/opt/ccnx-atmos/client.py
    6060}}}
    61   Answer the date questions appropriately, and observe that a .nc NetCDF file is created in the current directory containing precipitation data for the specified dates.[[BR]]
    62   Output for ''client.py'':
     61   Answer the date questions appropriately, and observe that a .nc NetCDF file is created in the current directory containing precipitation data for the specified dates.[[BR]]
     62   Output for ''client.py'':
    6363{{{
    6464[shufeng@researcher1 ~]$ /opt/ccnx-atmos/client.py
     
    7373Wrote to pr_1902_1_1_1902_1_2.nc
    7474}}}
    75   The .nc files:
     75   The .nc files:
    7676{{{
    7777[shufeng@researcher1 ~]$ ls
    7878pr_1902_01_01.tmp.nc  pr_1902_01_02.tmp.nc  pr_1902_1_1_1902_1_2.nc
    7979}}}
    80   Run ''ccndstatus'' again, and look at the statistics on the local ''ccnd''. You should see both that a substantial number of content items are cached on this machine (this is the meaning of the “stored” field under “Content items”) and that many more Interests have been seen.[[BR]]
    81   Output for ''ccndstatus'':
     80   Run ''ccndstatus'' again, and look at the statistics on the local ''ccnd''. You should see both that a substantial number of content items are cached on this machine (this is the meaning of the “stored” field under “Content items”) and that many more Interests have been seen.[[BR]]
     81   Output for ''ccndstatus'':
    8282{{{
    8383[shufeng@researcher1 ~]$ ccndstatus
     
    106106 ccnx:/ccnx/%F8%FD%A2o%23%7C%C7%EE%87w%EC%AA%F6%B6J%83%E4%9C%D9%20%B7%10f9%9D%87%EF%F8%10~%07%AF face: 0 flags: 0x17 expires: 2147477917
    107107}}}
    108   Next, log into ''researcher2'' and issue the same command. Observe that it takes much longer at each step, does not terminate, and no .nc file is created. This is because the ''ccnd'' on ''researcher1'' had routes to the precipitation data requested by Atmos, but researcher2 does not. Issue the following command to install the appropriate routes:
     108   Next, log into ''researcher2'' and issue the same command. Observe that it takes much longer at each step, does not terminate, and no .nc file is created. This is because the ''ccnd'' on ''researcher1'' had routes to the precipitation data requested by Atmos, but researcher2 does not. Issue the following command to install the appropriate routes:
    109109{{{
    110110ccndc add ccnx:/ndn tcp router
    111111}}}
    112   Note that the ''ccndc'' command takes a content path (ccnx:/ndn) and binds it to a network path (in this case, the host ''router'', which is a valid hostname on the experiment topology, resolving to an IP address on the ''router'' machine). It can also be used to delete routes with the ''del'' subcommand. 
    113   - '''Question 1.1 A: ''' [[BR]]
    114   From ''researcher2'', fetch the same data again (from 1902/01/01 to 1902/01/02), and record the fetch times reported by ''client.py''. It prints out the time take to pull each temporary file along with the concatenation and write time. Then fetch 1902/02/03 to 1902/02/04, and record those fetch times. Fetch 1902/02/03 to 1902/02/04 a second time, and record the new times. Which transfer was longest, and which was shortest? Knowing that each ccnd caches data for a short period of time, can you explain this behavior?
    115   Outputs:
     112   Note that the ''ccndc'' command takes a content path (ccnx:/ndn) and binds it to a network path (in this case, the host ''router'', which is a valid hostname on the experiment topology, resolving to an IP address on the ''router'' machine). It can also be used to delete routes with the ''del'' subcommand. 
     113   - '''Question 1.1 A: ''' [[BR]]
     114   From ''researcher2'', fetch the same data again (from 1902/01/01 to 1902/01/02), and record the fetch times reported by ''client.py''. It prints out the time take to pull each temporary file along with the concatenation and write time. Then fetch 1902/02/03 to 1902/02/04, and record those fetch times. Fetch 1902/02/03 to 1902/02/04 a second time, and record the new times. Which transfer was longest, and which was shortest? Knowing that each ccnd caches data for a short period of time, can you explain this behavior?
     115   Outputs:
    116116{{{
    117117[shufeng@researcher2 ~]$ /opt/ccnx-atmos/client.py
     
    151151Wrote to pr_1902_2_3_1902_2_4.nc
    152152}}}
    153   '''Answer:''' The first time fetching data from 2/3 to 2/4 took the longest, the 2nd time fetching data from 2/3 to 2/4 took the shortest time. [[BR]]
    154   Since ccnd caches data for a short period of time, the 2nd time researcher2 fetches data from 2/3 to 2/4, it fetches the data from local cache. Since researcher1 already caches data from 1/1 to 1/2, the `router` caches that data. As a result, researcher2 got the data from 1/1 to 1/2 from router cache.
    155   - '''Question 1.1 B:''' [[BR]]
    156   Browse the content caches and interests seen on various hosts in the network by loading their ccnd status page on TCP port 9695 in your browser (see Section 5, Hints, below). Which hosts have seen interests and have content cached, and why? [[BR]]
    157   '''Answer:''' datasource1, datasource2, router, researcher1 and researcher2 have seen interests and content cached. Since the data has passed them.
    158   - '''Task 1.2: Intent Propagation''' [[BR]]
    159   ''This task will demonstrate the behavior of Intent filtering during propagation. ''[[BR]]
    160   Log into the machine ''datasource1'' and run the command ''tail -f /tmp/atmos-server.log''. Next, run ''/opt/ccnx-atmos/client.py'' on both of the hosts researcher1 and researcher2. Enter 1902/01/15 as both start and end date on both hosts, and press <ENTER> on both hosts as close to the same time as possible.
    161   - '''Question 1.2 A:''' [[BR]]
    162   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]]
    163   '''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.
     153   '''Answer:''' The first time fetching data from 2/3 to 2/4 took the longest, the 2nd time fetching data from 2/3 to 2/4 took the shortest time. [[BR]]
     154   Since ccnd caches data for a short period of time, the 2nd time researcher2 fetches data from 2/3 to 2/4, it fetches the data from local cache. Since researcher1 already caches data from 1/1 to 1/2, the `router` caches that data. As a result, researcher2 got the data from 1/1 to 1/2 from router cache.
     155   - '''Question 1.1 B:''' [[BR]]
     156   Browse the content caches and interests seen on various hosts in the network by loading their ccnd status page on TCP port 9695 in your browser (see Section 5, Hints, below). Which hosts have seen interests and have content cached, and why? [[BR]]
     157   '''Answer:''' datasource1, datasource2, router, researcher1 and researcher2 have seen interests and content cached. Since the data has passed them.
     158   - '''Task 1.2: Intent Propagation''' [[BR]]
     159   ''This task will demonstrate the behavior of Intent filtering during propagation. ''[[BR]]
     160   Log into the machine ''datasource1'' and run the command ''tail -f /tmp/atmos-server.log''. Next, run ''/opt/ccnx-atmos/client.py'' on both of the hosts researcher1 and researcher2. Enter 1902/01/15 as both start and end date on both hosts, and press <ENTER> on both hosts as close to the same time as possible.
     161   - '''Question 1.2 A:''' [[BR]]
     162   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]]
     163   '''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.
    164164  - '''Task 1.3: Explore traffic patterns''' [[BR]]
    165165  ''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]]
    166166  Instrumentize your experiment using GEMINI following the instructions here: [http://www.protogeni.net/wiki/GeniTutorial GENIDesktop Tutorial]. [[BR]]
    167167  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]]
    168   - '''Question 1.3 A:''' [[BR]]
    169   Log into ''collaborator2'' and fetch the same dates. Which hosts transfer data? why?
    170   - '''Question 1.3 B''' [[BR]]
    171   Now fetch 1902/01/25 to 1902/01/31 from ''researcher2''. How does this transfer differ from the previous two? why?
     168   - '''Question 1.3 A:''' [[BR]]
     169   Log into ''collaborator2'' and fetch the same dates. Which hosts transfer data? why?
     170   - '''Question 1.3 B''' [[BR]]
     171   Now fetch 1902/01/25 to 1902/01/31 from ''researcher2''. How does this transfer differ from the previous two? why?
    172172
    173173 - '''3.2 Choosing Content Names'''  -- 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] [[BR]]
     
    188188  '''Implementation Hints:''' It is important understand how ''script.py'' uses NetCDF commands to extract relevant dimensions in the data files. The client (''client.py'') breaks up a user’s request into a collection of URIs (one for each day) and fetches them sequentially. For each URI, script.py generates a list of timestamps (a floating point number indicating the number of days elapsed since January 1, 1901). From the NetCDF data files, script.py 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]]
    189189  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]]
    190   - '''Question 2.1 A''' [[BR]]
    191   What general difference do you see in network behavior between these solutions?
    192   - '''Question 2.1 B''' [[BR]]
    193   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]]
     190   - '''Question 2.1 A''' [[BR]]
     191   What general difference do you see in network behavior between these solutions?
     192   - '''Question 2.1 B''' [[BR]]
     193   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]]
    194194
    195195 - '''3.3 Exploring the Impact of Caching''' -- Files to download: [http://www.gpolab.bbn.com/experiment-support/CCNExampleExperiment/cache.rspec cache.rspec]  [[BR]]
     
    200200  ''This task will demonstrate the benefit of opportunistic caching for static data used repeatedly.'' [[BR]]
    201201  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]]
    202   - '''Question 3.1 A''': [[BR]]
    203   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]]
     202   - '''Question 3.1 A''': [[BR]]
     203   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]]
     204   '''Answers:''' First time fetching data:
     205{{{
     206Start Date in YYYY/MM/DD? 1902/01/21
     207End Date in YYYY/MM/DD? 1902/01/24
     208Asking for /ndn/colostate.edu/netsec/pr_1902/01/21/00, Saving to pr_1902_01_21.tmp.nc
     209Time for pr_1902_01_21.tmp.nc 5.30908107758=
     210Asking for /ndn/colostate.edu/netsec/pr_1902/01/22/00, Saving to pr_1902_01_22.tmp.nc
     211Time for pr_1902_01_22.tmp.nc 9.64774513245=
     212Asking for /ndn/colostate.edu/netsec/pr_1902/01/23/00, Saving to pr_1902_01_23.tmp.nc
     213Time for pr_1902_01_23.tmp.nc 9.3288269043=
     214Asking for /ndn/colostate.edu/netsec/pr_1902/01/24/00, Saving to pr_1902_01_24.tmp.nc
     215Time for pr_1902_01_24.tmp.nc 9.40179896355=
     216Joining files..
     217Concat + write time 0.141476154327
     218Wrote to pr_1902_1_21_1902_1_24.nc
     219}}}
     220  Within 60 seconds, ask again:
     221{{{
     222Start Date in YYYY/MM/DD? 1902/01/21
     223End Date in YYYY/MM/DD? 1902/01/24
     224Asking for /ndn/colostate.edu/netsec/pr_1902/01/21/00, Saving to pr_1902_01_21.tmp.nc
     225Time for pr_1902_01_21.tmp.nc 0.168676137924=
     226Asking for /ndn/colostate.edu/netsec/pr_1902/01/22/00, Saving to pr_1902_01_22.tmp.nc
     227Time for pr_1902_01_22.tmp.nc 0.156650066376=
     228Asking for /ndn/colostate.edu/netsec/pr_1902/01/23/00, Saving to pr_1902_01_23.tmp.nc
     229Time for pr_1902_01_23.tmp.nc 0.159749031067=
     230Asking for /ndn/colostate.edu/netsec/pr_1902/01/24/00, Saving to pr_1902_01_24.tmp.nc
     231Time for pr_1902_01_24.tmp.nc 0.154557228088=
     232Joining files..
     233Concat + write time 0.135298967361
     234Wrote to pr_1902_1_21_1902_1_24.nc
     235}}}
     236  Between 60 seconds and 300 seconds, ask for the third time:
     237{{{
     238Start Date in YYYY/MM/DD? 1902/01/21
     239End Date in YYYY/MM/DD? 1902/01/24
     240Asking for /ndn/colostate.edu/netsec/pr_1902/01/21/00, Saving to pr_1902_01_21.tmp.nc
     241Time for pr_1902_01_21.tmp.nc 4.19592308998=
     242Asking for /ndn/colostate.edu/netsec/pr_1902/01/22/00, Saving to pr_1902_01_22.tmp.nc
     243Time for pr_1902_01_22.tmp.nc 4.18822002411=
     244Asking for /ndn/colostate.edu/netsec/pr_1902/01/23/00, Saving to pr_1902_01_23.tmp.nc
     245Time for pr_1902_01_23.tmp.nc 4.19812393188=
     246Asking for /ndn/colostate.edu/netsec/pr_1902/01/24/00, Saving to pr_1902_01_24.tmp.nc
     247Time for pr_1902_01_24.tmp.nc 4.18877005577=
     248Joining files..
     249Concat + write time 0.136485099792
     250Wrote to pr_1902_1_21_1902_1_24.nc
     251}}}
     252   Apparently local caching gives the best performance since the data is `local`. However, local cache can be out-of-date, that's why we typically use a small valid time range for local caches. Server side caching keeps the data `alive` in memory so the server does not need to generate the data and/or read from the hard disk every time that a client asks for the data (especially the same data) -- which, of course, helps to boost the performance too, as you can find from the above output.
    204253
    205254== 4. Other Projects ==