Proposal writing is an important skill -- you will be writing research proposals throughout the rest of your career and much of your success will be determined by how well you can convince others that the work you want to do is worth doing and that you have the ability to accomplish that work.
The purpose of the written proposal is to save you time by (1) identifying a specific goal and establishing that pursuing that goal is worthwhile and (2) developing a concrete strategy for meeting those goals and verifying that the proposed strategy actually matches the stated goals. (You would be surprised at how many research projects' strategies either do huge amounts of irrelevant work for a given set of goals or do a bunch of work and then realize that they still have not address their goals).
We will provide feedback on the written proposal to enhance both the written and in-class oral proposals.
The written proposal should follow the following format: Outline for written project proposal 3-5 pages
The following is taken from my notes on a recent project that I began: Summary: Experiment Set C: Background loading v. foreground We compare two cases. In one, when a server's reply indicates that customization should be applied, the extra stage in the pipeline is added immediately and the reply passes through it before being sent to the user. Case 2: when a server's reply indicates that customization should be applied, we hand the answer back immediately but begin downloading the customization program in the background. Once it is loaded, we update the customization pipeline for that server. Purpose: o Test the following performance model: under foreground mode, the first request will take (T_remote + delta_1) to handle (while the custom code is downloaded) and all subsequent requests will take T_local. Under background mode, the first k requests will take (T_remote + delta_2) to handle and the rest will take T_local. o Test hypothesis that background loading improves overall system performance. Proposed graph: x axis is elapsed_time, y axis is response_time for a request. Lines in graph represent different programs under test in either foreground or background loading mode: PROGRAM=null program MODE=foreground PROGRAM=null program MODE=background PROGRAM=adrot+hit count MODE=foreground PROGRAM=adrot + hit count MODE=background PROGRAM=catalog application MODE=foreground PROGRAM=catalog application MODE=background Suppose that a request to a remote service takes T_remote, a request to the local copy of the service takes T_local. This set of experiments will (a) test the hypothesis that the model is correct, (b) quantify k, delta_1, and delta_2, and (c) test the hypothesis that background loading is beneficial: if k and delta_2 are small and delta_1 is large, then this experiment will support using background loading. Otherwise, this experiment will tend to argue against using background loading. MILESTONES: MILESTONE C1: customization programs written MILESTONE C1-1: nullNS.jar written DONE MILESTONE C1-2: we don't want NULL, we want a program that changes the uncachable reply to become cachable. Write MakeCacheable.jar 8.6.99 MILESTONE C1-3: complete adrot, hit count downloadable services 8.13.99 MILESTONE C1-4: complete pages to be accessed to install and use services 8.13.99 MILESTONE C2: complete driver script to do repeated timed access 8.17.99 MILESTONE C3: run experiments MILESTONE C3-1: test system with all machines on LAN 8.17.99 MILESTONE C3-2: install server at far site (e.g., Duke or Washington) 8.13.99 -- get started early on this! MILESTONE C3-3: run experiment (clients on UT LAN, server on far site) 8.24.99 MILESTONE C3-4: run experiment (clients on modem or ISDN, server on far site) 9.1.99 MILESTONE C3-5: graph results; iterate experiments if needed 9.1.99 MILESTONE C3-6: update section 5.B of the paper describing experiments and results 9.8.99