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:
The following paper concentrates on the social aspects:
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.
Top //
6.033 home //
Last updated $Date: 2003/05/06 00:37:27 $ by $Author: athicha $
Design Project 2 Frequently Asked Questions: Updated 5 May 2003
Questions or comments about this web page? Send e-mail to
6.033-webmaster@mit.edu.