14:332:423            Computer and Communication Networks

Course Projects

There are two types of projects in this course:

See example reports for student TCP projects.  More examples of student project reports will be made available to course instructors upon inquiry.

The purpose of this project is to provide the students with hands-on experience with computer networks. I believe that hands-on experience leads to deeper understanding of the class material.

There are three deliverables for this project:

  1. Document describing the software design
  2. Live demonstration of the software
  3. Final report describing the software and simulation results.
The due dates for project deliverables are listed here.
                ♠ ♥ ◊ ♦

1.   Simple TCP Protocol Simulator

First go to this web site and download the TCP protocol simulation software and its PDF documentation. To run the software, follow these simple instructions.

This software, written in the Java programming language, implements a simple network simulator which simulates the TCP protocol. See the lecture notes for description of the TCP protocol. Curently the simulator supports Tahoe, Reno, and NewReno versions of the TCP congestion control algorithm.

2.   Project Teams

Each team consists of ≤5 students. All students in a team are working on the same project. Requests for working individually or with a smaller team cannot be accommodated due to the staff shortage.

You should form the team by the date given here and notify by email both the TA (if any) and the instructor about the team member names and their email addresses.

All team members must take part in all project activities, although responsibilities may be divided so that different members take lead in different activities. But, no activity should be done exclusively by a single person. While the volume of work of each group member on each project component may not be equal, their contribution to the overall project should equal out.

Many students find team work difficult due to different personal interests and working habits. Therefore, each student should keep track of his or her contributions to the project. The exact breakdown of individual contributions must be provided to the instructor for each deliverable, so the individual grades can be fairly assigned.

3.   Team Work

Here are some suggestions (none of this is required!) about team work:

The team meetings should be structured to involve:

Saying that “nobody asked me to do this or that, or, I did everything that I was asked to do” is an unacceptable excuse. Each team member should be proactive and not wait passively to be assigned responsibilities. Do not ask others what should be done; rather, take initiative and suggest what should be done to make your project successful. Take every opportunity to redistribute and/or rotate the responsibilities, make your personal suggestions be heard! Many times defining the problem and determining what needs to be done is more difficult than actually doing it. Hence, problem defining and task assignment must be contributed to by all team members, rather than by the team leader alone.

What is the role of a team leader?

First, keep in mind that having a team leader is optional. You should elect the team leader only if you believe this would facilitate your group work.

The role of a team leader should not be misunderstood. The team leader is expected to provide organizational and logistical support, that is, to organize team meetings and keep track about work progress. The team leader is not expected to set the objectives, partition the tasks, and devise solution strategies. These responsibilities must be shared equitably by all team members.

It is a good idea to select the team leader based on his or her social/personal skills, rather than their technical skills and knowledge. Past experience has shown that people with poor social skills turn out to be poor leaders and their teams end up being dysfunctional, regardless of their technical knowledge.

There are neither benefits nor responsibilities for the team leader. The leadership is a voluntary responsibility, just to facilitate the team work: help organize the meetings and remind the team members about commitments and deadlines. The team leader will not receive any rewards (e.g., higher grade) for serving in this capacity. The leader is also not accountable for “failing to lead” and cannot be blamed for the lack of communication skills or general lack of success of the team’s project. For example, the leader has no such responsibilities as “knowing what needs to be done,” assigning work loads (fairly or otherwise), or distributing the responsibilities. This must be agreed upon by consensus. Most importantly, each team member must be proactive, rather than waiting to be assigned the duties by the team leader or anybody else.
Remember, All team members are equally responsible for all aspects of the project. Each deliverable will be graded as a whole so all team members should ensure that a bad part does not downgrade the whole.

What if your team is not functioning well?

If you notice that your team does not function well or the team leader tries to misuse his or her role, and this could negatively impact your project performance, you should make every effort to discuss this with other team members. If the “problematic” team members (including the team leader) refuse to cooperate, you should discuss your concerns with the instructor, the sooner the better.
Complaints about poor team functioning expressed at the end of semester will be ignored.

4.   Software Design Document

For this deliverable, every team is expected to submit a document describing the design of the software for their project. The due date is given here.

The design document should contain the following:

  1. Cover page using the same format as the final report.
  2. Breakdown of individual contributions to the project for each team member as specified for the final report.
  3. Flowchart of the program that you will develop to complete the assignment:
    It makes sense, although it’s optional, to split the chart in three parts, to reflect the structure of the simulated network:
    1. Flowchart of the algorithm running on the sender
    2. Flowchart of the algorithm running on the router
    3. Flowchart of the algorithm running on the receiver
    Here is a partial flowchart for the reference example.
    To learn what a flowchart is, grab an intro book on programming or visit the Wikipedia flowchart webpage.
  4. Brief textual description of the flowchart:
    1. Briefly explain the algorithm
    2. Define each variable or parameter used in the flowchart
    3. State what programming language and the development environment you’ll use; etc.
Submit the flowcharts only for the modules that you will develop anew or modify from the existing simulator implementation. Do not submit flowcharts for the existing modules that you will use unmodified.

Where to find information about TCP:

  1. Lecture notes (Chapter 2), available here
  2. The Internet requests for comments:
     RFC-2581: http://www.apps.ietf.org/rfc/rfc2581.html
     RFC-2001: http://www.apps.ietf.org/rfc/rfc2001.html
  3. The course textbook, Peterson & Davie, Sections 5.2 and 6.3

Email your algorithm design as a single PDF document on or before the due date   (get a PDF writer you can use from Windows).
Submit only one design document for each team.

5.   Project Demo

For this deliverable, every team is expected to give a live demonstration of the software they developed for their project. The presentation date is given here.

The project demo will be held during a class period in the regular classroom. Each demo shall last no more than 15-min. If you have preferences regarding the order of presentation, please send ASAP an email to the TA to schedule your demo.
If you cannot bring your own notebook/laptop, please contact the TA immediately to arrange a computer to demo your software. In this case you should bring your presentation software and slides on a USB thumb memory card.

Each group should email us at least one day before the demo, stating explicitly that they will present their project. Do this even if you will use your own computer and do not care about the presentation order.
We need this notification to plan the presentations. If we do not receive an explicit notification, we will assume that this group does not plan to present and will not be able to accommodate last minute requests.
The students who did not send this notification will not be allowed to present.
All team members should attend the demo presentation. We will assume that the absent students were not involved in the project work.
The students who cannot make it should send email before the demo, with the reason for their absence explained.
The demo should include:

  1. brief (no more than 3 slides!) introduction to your project
  2. live demonstration of your program
  3. slide presentation of different charts obtained by running your software with different input parameters (see the statement of your programming assignment in the lecture notes as to what charts to prepare.
Please bring a printed copy of your slides handouts for the TA and the instructor.
Note: Do not prepare any report for the demo. The report will be required as described next.
Make sure to email us the breakdown of individual contributions immediately after the demo. If you don’t, we will assume that all team members contributed equally to the demo.

6.   Final Report

For this deliverable, every team is expected to submit a document describing the design, implementation, and experimental results. The due date is given here.
Only one report is required for the project, to be submitted by the whole team (one report per team). This report should be a self-contained document, including any and all flowcharts or other documents that you handed in earlier in the semester.

Example reports from past years can be found here.

Every report must have a cover page containing:
  . the course title,
  . group number,
  . project title,
  . submission date, and
  . all team-member names.
Negative points will be assigned to reports missing- or having an incomplete cover page.

The second page of each report must detail the breakdown of individual contributions of each team member to the project. Quantify, as a percentage, each student’s contribution to the project components:
  . algorithm design,
  . coding,
  . debugging,
  . analysis of results
  . report preparation,
  . Other: any other project-related effort.
The reports missing- or having an incomplete contributions breakdown page will be returned for revision before grading.
If all team members feel that everyone contributed equally to the project, just write “equal contributions”.

The rest of the report must contain the following sections:

  1. Introduction:
    State the objective of your project (you can copy your assignment and elaborate as needed -- remember to include the revisions of the assignment, if any);
    Provide some background information.
  2. Software Design:
    Provide a block diagram of your system before presenting the detailed algorithm flowcharts;
    Describe in detail your algorithm, as a pseudo-code or via a flowchart. For any detail of the flowchart that needs additional explanation, put a footnote label on the flowchart, and provide the footnote text on a separate page;
    Specify exactly the user-controllable parameters to be entered when running your program: what are the allowed values, what are the recommended values, are there any values that should be avoided?, etc.
  3. Implementation:
    Specify the programming language and any other tools used for the development;
    Describe briefly the content of each source-code file (describe only the files that you modified significantly from the original, or the new files that you introduced);
    Provide a brief user’s manual (a README.txt document) describing how to run your program and modify the user-controllable parameters.
  4. Results and Discussion:
    Present your experimental results in graphical charts and tables (you can use Microsoft Excel for this, see example);
    Each chart/table should have a caption and should be referenced and described in the text;
    Calculate the sender utilization, where applicable (state explicitly the exact formula you used to calculate the sender utilization).
    Discuss the results in detail, provide technical explanations and comments on the system performance, etc. Explain any unexpected or non-obvious results.
    Cite the literature or web sources where the reader can find more information about the theory of the observed phenomena.
    Reports that contain only charts but without description and explanation will receive a poor grade. Technical discussion and explanation of the results is critical.
  5. References:
    List all the references (books, journal/conference papers), web pages (include URL and webpage title) that have been used in the project.

When you get your program working, run it and plot the charts similar to those in the class notes. Calculate the sender utilization, where applicable.

Email your report as a PDF file (get a PDF writer you can use from Windows).
NOTE:  Do not mail any other formats, such as Microsoft Word.

7.   Project Grading Policy

Each student must be aware that a major part of his or her final grade depends on the team project. The failure to cooperate and invest equitable amount of effort may lead to undesirable outcomes. To help us assign the grades fairly, you are required to exactly specify the individual contributions to the project (as described above).

Each report will be graded as a whole and the grade will be assigned. Next, the total grade will be divided up to individual team members, based on the reported contributions breakdown and the judged quality of the components of the project. Hence, it is quite possible that members of the same team receive different grades.

Late reports will be levied a late penalty of 10% per day, up to 3 days late. After that, no credit will be given, unless more than 40 % of team members (e.g., at least 3 out of 6) provide a written excuse from a physician. Since the deadlines are known well ahead, there will be no extensions for any of the deadlines. Please don’t bother asking.

See also the overall course grading policy here.

Contact the instructor immediately should you have any questions or concerns about the grading policy.


Ivan Marsic
Thu Oct 6 00:11:52 EDT 2011