6.033: Computer System 
Engineering

6.033: Computer System Engineering - Spring 2003

------------

Design Project 2 Frequently Asked Questions: Updated 5 May 2003

A design project is a different beast than a quiz. Like in real life a design project is underspecified and it is your job to complete the specification in a sensible way given the overall requirements of the project. Like with designs in practice, the requirements often need some adjustment as the design is fleshed out. Questions and answers will be posted here as they are generated.


Q: The design goals for StudentTracker specify an annual downtime of no more than 3 hours in aggregate, and 10 minutes for a single incident. How am I supposed to use that information?

A: The reason we included this goal was to get you thinking about what kind of availability is typical, and what mechanisms you might need to improve it. Suppose your design relies on a single machine acting as a central server, running Linux say. Such a server can only be expected to give about 99% availability, which corresponds to about 100 hours of downtime a year. And suppose your plan for handling crashes is that you'll page the system administrator to come and reboot. That will certainly not be possible within ten minutes. So you'll need to figure out a scheme that will do better.

Q: So is that all there is to developing high availability systems?

A: No. In practice, you'd also need to think carefully about your software engineering practices. Special mechanisms won't help if they don't work because they were implemented badly. Of course, these issues are outside the scope of this project; they belong to 6.170 and not 6.033. But you should bear in mind that even the most talented implementation team will not be able to build a reliable system from a design that is too complicated, or not clearly explained.

Q: What if the infrastructure -- MITNet, for example -- isn't good enough? Does that mean I have to design my own?

A: No. You can assume that MITNet, for example, is good enough, but you should specify clearly what 'good enough' means.

Q: Can we design our own cryptography and crypto protocol?

A: You must have missed Prof. Lampson's lectures and haven't read chapter 6. You should not design your own crypto, because you will most likely make a mistake. Try to use existing crypto pritimives and protocols, such as SSL.

Q: What assumptions should I make about the performance of the RFID tags?

A: You make any assumptions that are reasonable for tags available today. For example, the Tag-It inlay, made by Texas Instruments, is a read/write passive tag that can store 256 bits, and has a read range of 1 meter; using the Series 6000 reader, about 20 such tags can be read in a second. Tag-Its cost about $1.50 a piece bought in batches of 100. Transcore's AT5100 Toll Tag holds 120 bits, which are factory set, and has a read range of 3 meters. You can find out more information about available technology by looking at manufacturers' data sheets. See, for example, the product sites for Texas Instruments and Transcore. The customer FAQ at the TI site is helpful.

Q: How many design outline one-pagers should we do? One per team or one each?

A: One per team.

Q: Are there any cost constraints on the design? Is there a limit to the number of readers, for example?

A: There is no explicit cost constraint. In your report, however, you should justify your design decisions based not only on considerations of performance and reliability, but also of cost effectiveness. It has been said that an engineer can do for a cent what any fool can do for a dollar; the essence of design is in the tradeoff between cost and benefit.

Q: Can I rely on Athena to provide authentication, privacy, reliability, etc?

A: Students asking this question seem to be a bit confused about exactly what Athena is. Athena is not a closed system with its own operating system, protocols, etc; rather it is a distributed computing environment built on standard operating systems, with some centralized services, and workstations specially configured with a network transparent file system and certain additional applications. The comment in the design project handout saying that you can exploit Athena's resources means that you can make use of applications such as zephyr, or have readers communicate over MITNet, our local area network. For authentication, you will likely have to invent your own protocols; of course you can build these on top of standard protocols such as TCP/IP.

Q: Can I run a program on the reader?

A: You should think of the reader as a general-purpose computer, with the reading device attached as a peripheral. Your system will include a program that runs on this computer. You'll have to invent some appropriate interface by which the program obtains data from the reader, the structures it uses to package up this data, and the protocols it uses to send the data across the network.

Q: The Student Tracker application has serious societal implications. I'm disturbed that the staff of 6.033 have asked me to design a system that could be used to track students for all kinds of insidious purposes.

A: You're right to be concerned. In fact, one of the reasons we chose this problem was precisely that it highlights some important ethical and societal concerns.

Technology is never neutral, and most computer systems have effects both good and bad. A system for tracking people has a range of applications from the mundane (such as helping students locate their friends) to the sinister (such as tagging foreigners). A system developed with the best of intents (such as locating doctors in an emergency room) might be put to dubious use (such as providing evidence for malpractice suits). The more powerful and disruptive the technology, the greater the potential for both benefit and abuse. Anonymous remailers, for example, can be used by dissidents to voice dissent and plant the roots of democracy in a totalitarian regime, or by kidnappers to deliver ransom demands.

An important part of your education as an engineer is to develop a sensitivity for these issues, so that the systems you build will not be exploited for unethical or damaging ends. Sometimes, you will be able not only to identify the problem, but also to provide a partial solution in the technology itself. By designing appropriate access control and security mechanisms, for example, you should be able to make it less likely that student location information will fall into the wrong hands. At other times, your role as engineer will be to warn those with a less sophisticated understanding of technology of its potentially harmful implications, and suggest policies surrounding use and abuse that can help mitigate concerns that cannot economically be mitigated by technical means. This project gives you an opportunity to do both. You should also be able to delineate clearly the limitations of your system, and explain how its protections may nonetheless be overcome.

We encourage all students to consider these issues deeply. If you are particularly concerned about them, you may choose to devote a significant portion of your writeup to these questions. However, make sure that you pay enough attention to the technical aspects of the design and analysis. Of course, you are also free, as the DP2 handout explains, to choose a completely different problem: one in which societal concerns are less (or perhaps more!) significant.

Q: Our team is thinking of choosing a real-world application away from M.I.T. Can our design make use of a Zephyr-like component?

A: Yes, but you must make a believable case that the proposed component really is applicable to the proposed environment. Major subsystems like Zephyr may assume the existence of an externally provided community infrastructure, such as a reasonably trustworthy method of knowing who are members of the community and who are not, and identifying individuals. Simply saying "use Zephyr as a way of communicating between the post office and its customers" would not be sufficient; that proposal would require a lot of thought and design to develop the necessary supporting infrastructure or some alternative.

Q: Can an RFID tag use timing to estimate its distance to a reader?

A: If you are willing to spend enough money on the design and manufacture of a new all-singing, all-dancing RFID tag, it can do about anything you can design. But we expected you to use standard, off-the-shelf passive RFID tags. It is all they can do to respond. You should check some of the citations in the bibliography to learn about their capabilities and how they work.

Q: Is it possible for readers to track more than a single RFID tag at once?

A: If there are several RFID tags within its range, a reader can activate and read them one at a time. You can assume the reader has solved that problem, and all you need to do is make sure that you don't expect it to read more tags per second than its specification calls for. If you are curious to find out how reading in the presence of multiple tags works, you can find out more about this at http://www.autoidcenter.org/aboutthetech_research.asp, a page on the MIT web site that we listed in the DP2 handout. This page contains a long list of papers, some of which deal with "collision" problems. In particular, the following paper describes a "query tree" protocol to allow a reader to track more than one RFID:

Q: In the Student Tracker application, should we assume that the tags are attached to people in any specific way? Will every person have exactly one tag? Should the system be for novelty purposes only or will it be used to control access to dorms, labs, and bursar accounts?

A: Those are decisions to be made by the system designer--you!

Q: Where can I find out more information about how RFID tags work?

A: The MIT website that we mentioned in the DP2 handout is a reasonable starting point. On that web site, the page at http://www.autoidcenter.org/aboutthetech_research.asp contains a sizable pile of papers.

Among these are papers that explain various schemes for handling multiple tags in the range of a single reader. For instance, the following paper describes a "query tree" protocol to solve this problem:

Efficient Memoryless Protocol for Tag Identification. Kai-Yeing Siu, Ching Law, Kayi Lee. Technical Report MIT AUTOID TR-003 .

The following paper concentrates on the social aspects:

Why Technical Breakthroughs Fail: A History of Public Concern with Emerging Technologies. Brian Cantwell. White Paper MIT AUTOID WH-016 .

Another source of information is the collection of resources at http://www.aimglobal.org/technologies/rfid/resources_for_rfid.asp. We suggest that you look over the "White Papers" on that page, starting with the document entitled "RFID Basics Primer".

------------

Questions or comments regarding 6.033? Send e-mail to the TAs at 6.033-tas@mit.edu.
Questions or comments about this web page? Send e-mail to 6.033-webmaster@mit.edu.

Top // 6.033 home // Last updated $Date: 2003/05/06 00:37:27 $ by $Author: athicha $