Design Project Two: Frequently-Asked Questions

An important lesson from the real world is that the customer's specification of the problem is nearly always incomplete and inconsistent: one of the jobs of the system designer is to discover those gaps and inconsistencies and figure out what to do about them. In some cases, the best thing to do is to make a reasonable assumption and proceed. In others, it is better to ask the customer what he or she really intended. But asking the customer doesn't always work: the customer may not have an answer and is hoping that the system designer will just do something appropriate. So please don't be surprised if this FAQ gives some answers that seem vague.

Last updated: $Date: 2007/05/02 14:18:32 $

Q: What date is Thursday, April 24th? (was listed due date for proposal)

A: Tuesday, April 24th, as on the schedule.

Q: Can the Tracker track anything other than the mapping from video stream name to video server?

A: No. The Tracker acts only as a name service. The Tracker should not store any information about which peers are listening to which streams.

Q: Can we use TCP to exchange messages (e.g., control messages) between peers?

A: Yes. Though the primary delivery mechanism for frames is UDP, you can use TCP for other messages.

Q: Can we assume that the video server has up-to-date information about the entire distribution tree?

A: Unlikely. While you can aggregate some information about the state of the distribution tree, it is probably unreasonable to assume that such information is complete and up-to-date. Should your design aggregate information like this, be sure to include bandwidth analysis of the extra load that this imposes on the video server.

Q: Does our design have to handle changes in peer bandwidth?

A: No. You may assume that each peer's bandwidth is both known to the peer and constant.

Q: Does our design have to protect against adversaries sniffing packets?

A: Yes. Your security scheme must ensure confidentiality of the secure streams against eavesdropping on the network packets.

Q: We have this awesome scheme that uses seven way redundancy, stream splitting, and auto reorganization of the distribution tree to maximize performance...

A: Remember that simplicity is a key design goal. Crazy awesome design often trades off against simplicity. Make sure you're on the right side of the trade-off.

Q: What does "As long as multiple peers do not fail at the same time, no peer will see performance degradation that is caused by peer failures" really mean?

A: Barring lots of dropped packets, downstream peers should have the frames they need in time to play them. If your design relies on reorganization of the distribution tree before downstream peers can once again receive frames, then you must provide analysis that shows that, with high probability, the reorganization will happen quickly enough and the new parent(s) will have the appropriate frames. If your design does not require repair first, then you must show analysis that demonstrates that there is sufficient bandwidth to supply all downstream peers now that a peer is missing.

Q: Can we assume a loose time synchronization protocol (like NTP)?

A: Yes. You cannot assume that it is extremely precise, but second-level accuracy is reasonable.

Questions or comments regarding 6.033? Send e-mail to the 6.033 staff at or to the 6.033 TAs at

Top // 6.033 home // $Id: faq.html,v 1.5 2007/05/02 14:18:32 benmv Exp $