Introduction. One of the features of 6.033 is that we discuss real systems, both successful and unsuccessful. To get beyond discussion and give you some direct experience with designing systems we also assign two design projects. As in the real world, these projects have (we hope) a simple high-level problem statement but when you get into the system design you will find that there are hard choices to make. And, as in the real world, it is your job to explore, understand, and explain what the best choices are, how to reconcile sometimes conflicting goals, and how to keep the complexity of your design under control. This term, the first of these design projects relates to World-Wide Web techologies.

The Problem. Netscape has an idea for a new type of Web browser that is intended to speed Web browsing. Netscape's idea is to have a Web browser optimistically prefetch Web pages that are referenced by the displayed page. For example, if "www.mit.edu" references "www.mit.edu/courses", then while you are reading the main MIT page the browser may choose to prefetch the courses page.

Your job is to design a new Web browser that realizes Netscape's vision. At a minimum, your design should address the following points. A good design may go well beyond this short list.

1. How will your design use concurrency and threads in the browser to manage connections with remote sites?

2. How will your design coordinate the actions of independent threads?

3. How will your design decide what to prefetch? Specify your prefetch algorithm.

4. How will you measure the performance of the browser's connection to the Internet and the performance of remote servers, and will this information be used in your prefetching algorithm? For example, how about people who are using the browser over a dial-up telephone line?

5. When will your design stop a prefetch in progress, and how will stopping a prefetch be implemented?

6. How will your design manage the cache of prefetched pages, including what replacment algorithm will be used? For simplicity, ASSUME that pages that contain time critical data (such as stock prices) and pages that are created in a response to user input are named by URL's that contain a "?" character. Do not cache these pages. In addition, you should also IGNORE the complexities introduced by pages that include Java applets and other dynamic constructs.

7. How might your design alter the user interface for the browser? Are there additonal visual cues you can implement?

8. If every browser used your design, what would be the effect on overall Web performance?

You should assume that HTTP/1.1 will be used by the browser. See http://www.w3.org/Protocols/rfc2068/rfc2068 for the specification. In addition, www.w3.org has a wealth of other information. You may also wish to look at www.netscape.com and www.microsoft.com for background information on their browsers.

Your report. Your paper should be 8 to 10 pages in length. You should start by explaining to your intended audience the background of the problem in terms that audience can understand. Next, describe what you have decided are desirable properties of a solution. Then give your solution and explain how well it achieves (or fails to achieve) the desirable properties. Throughout the paper you should justify each of your design decisions, especially in relation to alternative decisions that you could have made. You will be more convincing if you say not just why your idea is good, but why it is better than the alternatives. (For example, if another approach would meet all of the objectives perfectly, but the cost would be 100 times higher, then you should mention that as a reason for choosing your less-general but cheaper approach.)

Write for an audience consisting of colleagues who took 6.033 five years ago. That is, they understand the underlying system and network concepts and have a fair amount of experience applying them in various situations, but they have not thought carefully about the particular problem you are dealing with. Assume that your paper will also be used to convince your friend's computer guru that you have the right idea. Finally, give enough detail that he can turn the project over to that guru for implementation with some confidence that you won't surprised by the result.

When evaluating your report, your instructor will be looking at both content and writing.

Content considerations:

• Does your solution actually address the stated problem?

• Do you explain your decisions and the trade-offs?

• How complex is your solution? Simple is better, yet sometimes simple won't do the job. But unnecessary complexity is bad.

Does your solution fit well with the rest of the system? If your solution requires modifying every piece of hardware, software, and data in sight, it won't be credible, unless you can come up with a very good story why everything needs to be changed.

How extensible is your design? Are there opportunities for later addition of desirable features that you decided to omit?

Writing considerations:

• Is the report easy to comprehend?

• Is it well organized and coherent? Does it start by summarizing the problem and your solution? (Remember, you aren't writing a mystery novel. Perhaps you should start with an abstract)

• Does it explain the approach or architecture conceptually before delving into details, components, and mechanics?

• Does it use diagrams where appropriate? (A frequent problem when people use word processors is that they try to express everything in words, either because the word processor doesn't make it easy to include diagrams, or they haven't ever learned how to use the drawing features. Pictures can communicate some ideas far better.)

• Does it use the concepts, models, and terminology introduced in 6.033? If not, does it have a good reason for using a different universe of discourse?

• Does it address the intended audience?

You can find other helpful suggestions on writing this kind of report in the M.I.T. Writing Program's on-line guide to writing Design and Feasibility Reports.

Phase Two writing considerations: If you are enrolled in the 6.033 writing practicum, you don't need to do anything special; your practicum instructor will explain how the report will get you credit for the Phase II writing requirement. If you are not enrolled in the practicum, AND you want us to forward your design project report to the writing program as your phase II writing project, please say so on the cover page, and make sure that your report is at least 8 pages long. Note also that the writing program has a rule that they will accept only reports that earn a B or better from the class in which they originate. Finally, be aware that the second design project will probably be a team project, and thus much more difficult to tailor to the needs of the writing program than this one.

Collaboration: This project is an individual effort. You are welcome to discuss the problem and ideas for solution with your friends, but if you include any of their ideas in your solution you should explicitly give them credit, and you should be the sole author of your report.

Schedule: Your report is due in recitation Thursday, March 19, 1998.