Dacopan project MEETING MINUTES
Jan 28th, 2004
Meeting
Jan 28th, 2004, at 14:00
Department of Computer Science, room C454
Attendance
Markku Kojo, client
Alejandro Fernandez Rey
Carlos Arrastia Aparicio
Jari Aarniala, secretary
Jarkko Laine
Turjo Tuohiniemi, instructor
Vesa Vainio, chairman
Andrei Salo
Andrei Ananin
Dmitry Korzun, instructor
Kirill Kulakov
Mikhail Kryshen
Absent
Jonathan Brown
1. Start
Mr. Vainio started the meeting at 14:15.
2. Assessment of the situation
While waiting for the client to arrive, questions prepared for the
client in the last meeting were reviewed and prioritized. Mr. Korzun
reminded the group that the main goal for this project is experimenting
with the distributed software development process, so the requirements
for the software itself should be kept simple.
3. Discussion
3.A - Organizational issues
Each member of the project group will be able to register an account to
the TWiki system soon. Mr. Arrastia will hold a presentation of the
TWiki system during the meeting on Thursday. The Thursday meeting was
re-scheduled to start at 09:00.
3.B - Communications with the client
At 14:34 the client, Mr. Kojo arrives. It is agreed that during the
first phase of the project (while the team from Petrozavodsk is still
here) three face-to-face meetings with the client will be held:
- Friday Jan 30th at 12:15 (location will be decided later)
- Tuesday Feb 3rd at 16:15 in room C475
- Friday Feb 6th at 12:15 (location will be decided later)
During the next phase each face-to-face meetings with the client can
be directly arranged with him via email. A presentation of an existing
data communications visualization program (Sea Lion) can be held during
the meeting on Jan 30th or Feb 3rd.
3.C - Presentation from the client
The client held a presentation on what kind of a program he's hoping
the DaCoPAn group can produce. These are the main points of the
presentation:
- The program should be able to visualize communication (messages)
between two endpoints in a network
- Real data (real packet traces) should be used as the starting
point for the visualization. tcpdump, a standard tool freely
available e.g. for Linux can be used for collecting the data.
- The tcpdump logfiles collected from the two endpoints can then
be used to reconstruct and visualize the message exchange (including
dropped packets etc.) between the two hosts.
- When logging the data, the built-in filters of tcpdump can be used
to leave unwanted data out of the log files
- The tcpdump log files should be analyzed by an analyzer that outputs
a file in an intermediary format, that can be in turn be visualized
by the visualizer component
- The program should be capable of showing all of the details of
the message exchange as obtained from the tcpdump log files, but
perhaps not by default, i.e. the level of detail can be specified
by the user
- The data to be shown includes protocol name, port, sequence numbers,
ip addresses of the hosts etc.
- More details could be shown when placing the mouse over a certain
packet in the visualizator
- The user should be able to pause, stop and play the animation, as well
as rewind and forward it (for example: "Go back to message #2" or
"Forward to message #100").
- The animation speed should be tunable
- As an optional requirement, it would be good if the user could
schedule the animation to stop at certain times and then continue
playing automatically, much like timing a PowerPoint presentation.
This should be taken into account in the design phase.
- The program should be able to visualize messages on different
protocol levels, for example:
application level (HTTP) - transport level (TCP) - network level (IP)
- The user could select a more high-level or low-level view on the fly
- An example of a lower level protocol that should be supported is
ARP (Address Resolution Protocol)
Mr. Kojo reminded us that we should first be clear on the more
high-level issues before delving into too much detail of the technical
issues, which can be postponed.
3.D - Questions from the project group
* Is the main goal of the program to be educational or should it be
aimed at research purposes?
- First educational, research purposes come second. Educational
purposes serve research as well.
* What are goals for each of these purposes?
- Educational:
- Clear animations, even if things are trivial to the more
advanced users, they should be clear to students
- Research:
- For example, performance analysis of TCP networking.
More on this subject during the Friday / Tuesday meetings, when
the Sea Lion software that's capable of visualizing communications
using time-sequence graphs will be demonstrated. Time-sequence
graphs would be a useful feature for more advanced studies.
* Is the program mainly intended for lecture/classroom use or is it
desirable that the students can use it on their home computers as
well?
- Both, ideally the program would be able to replace "hand-written"
PowerPoint presentations of network communications by creating
automatic presentations
- The lecturer could use the analyzer tools to create pre-defined
data files for the students to view at home
- The whole program (both analyzer and visualizer components) could
be made available to the public, but gathering tcpdump logs is not
something that a regular user can easily do, so the analyzer may not
be of much use to the general public
- In order to create packet loss and other specific circumstances,
special programs can be used to make the pre-defined tcpdump log
files more interesting for teaching purposes
- The program could have a web interface (for example, a Java applet)
so that it's easily accesible to students from different locations
* Should the program be suitable for teaching the students of data
communications courses?
- Yes, both Data Communications I and II
- Preferably the program should be open for further extensions and
development for features to be used during more advanced studies
* Should we assume that the students don't have any experience on
data communications when they use the program?
- It can be assumed that basic ideas of data communication have
already been discussed with the students before they start using
the program, which can then be used to deepen their knowledge
* What should the students learn in DC I and II, using this program?
- For example TCP: what messages are sent? in what order? how does TCP
recover from erroneous situations? how does the TCP slowstart
algorithm work?
- The program should be able to show parameters and events such as
congestion window size, timeouts as they occur, retransmissions etc
even though this information is not included in tcpdump files
- This will require e.g. a customized Linux kernel, and that's out of
this project group's scope. However, the intermediate file format
should be designed so that this information can be inserted there
manually. Later on, this could be done automatically, should some
other group choose to extend the functionality of the program.
* How many types of animation should the program be able to show?
- Message exchange is the only chart type to be implemented at the
moment, but other options can be thought of
* If there are many concurrent connections, how to select which
connection is visualized?
- Whoever is collecting the data using tcpdump should arrange so
that there is only one active connection when starting the logging,
this is the simplest option.
- Later on the user could possibly be able to select which connection
should be shown in the visualizator, or multiple connections could
be shown at the same time - this should be taken into account during
the design phase
* What if the clocks of the two computers are not synchronized?
- This is a problem, but a solvable one. TCP sequence numbers can be
used in which case the time on both endpoints isn't relevant.
The clocks of both computers can also be synchronized first,
although they may start diverting right away. The time difference
between the two hosts can be figured out and then added/substracted
to the timestamps
* Default level of information should be configurable by the user
- The user should be able to change the level on the fly
* Protocols that need to be supported
- Two or three application level protocols should be sufficient.
- For example:
Application level: FTP, HTTP, SMTP
Transport level: TCP, UDP
Network level: IPv4, IPv6
* Consider the possibility of adding more endpoints later on
- What would this mean for the intermediary fileformat, for example?
- No need to implement, just take into account
* Application level animation: what to show?
- For example for HTTP, the relevant header information should be
shown, the data sent by user is not relevant
- Also, they size of the payload (in bytes) should be shown
Mr. Kojo pointed out that the user interface requirements can be
thought out by the DaCoPAn group later on. Also, as a reminder, he
mentioned that the final product should be a educational tool with
room for future extension for use in more complex research problems etc.
Mr. Korzun asked about the deployment platform of the product. The
platform is still uncertain at this point, but preferably the users
should be able to run the visualizer on the computers of both
computer science departments involved in the project, for example
using a web browser. Mr. Kojo suggested that that the C language
might be suitable for the analyzer component whereas Java could be
used to develop the visualizer.
4. Introduction of members
At the end of the meeting, each member of the groups from Helsinki
and Petrozavodsk introduced themselves to the client.
5. Action points
- Mr. Arrastia will prepare a presentation on the TWiki system for
the meeting on Thursday Jan 29th
- Each member of the group will register an account on the TWiki
system to be able to edit the content
- After each member has created an account for themselves, the
registration feature will be disabled for security reasons
6. End
Mr. Vainio ended the meeting at 14:08.
Go back to DaCoPAnDocumentation