Dacopan project MEETING MINUTES
Jan 30th, 2004
Meeting
Jan 30th, 2004, at 12:00
Department of Computer Science, room C475
Teollisuuskatu 23, Helsinki
Attendance
Jarno Saarto
Markku Kojo, customer
Dmitry Korzun, instructor
Kirill Kulakov
Andrei Salo
Andrei Ananin
Mikhail Kryshen
Jonathan Brown, chairman
Carlos Arrastia Aparicio
Alejandro Fernandez Rey
Jarkko Laine, secretary
Jari Aarniala
Turjo Tuohiniemi, instructor
Absent
Vesa Vainio
1. Start
Mr. Brown started the meeting at 12:15.
2. Assessment of the situation
Second meeting with the customer Mr. Kojo. The project plan is being
written (the risk analysis part is already in CVS, and a draft of the
introduction has been made by the Petrozavodsk team) and the requirements
elicitation is going on. All members have been registered in TWiki web
system and the CVS repository is fully functional. All the information
about the use of those tools is available on the web sites of the project.
3. Discussion
3.A - Presentation on Sea Lion
Mr Saarto led a presentation about the software "Sea Lion" which is a
data communications visualization program working on data from "Sea Wind",
a network emulator. This program shows how packets and acknowledgments are sent
between 2 hosts in a network, data bytes sent in function of the time.
It shows information about packet losses as well, if those are emulated
by Sea Wind. The detail of information to be shown can be selected, and is
presented statically on a graph. "Sea Lion" is particularly useful for research.
But with animation, the way in which TCP protocol works would become much
clearer to the user of the program.
3.B - Questions for the customer
* Which are the target usergroups? Who will be benefiting from the program?
- First audience: students that are learning data communication basics.
- For teachers, their teaching work will be eased by this tool.
* What kind of exercises will be presented with this tool?
- Exercises showing specific behaviours of the protocols such as:
what happens when 2 consecutive packets are lost, slow start,...
That way students can collect information from the tool and figure out
easier what happens.
- Self studying.
(Not many more exercises have been tought already by the customer)
* How important is to visualize real complex data? Why not let the user play
with simple scenarios?
- The goal is to give the user a basic level of detail and then the
capability to increase it.
* Which could be a better product for the customer's needs: one that uses
real data from tcpdump logs or one that uses simulated data?
- The primary target is the animator. A basic simulator is feasible but
will demand additional work for the limited resources available.
- All existing simulators have flaws and some special situations are not
implemented in them. This is specially bad for the educational purposes.
- Using existing open source protocol simulators is not a solution, as
we should study that those don't contain errors.
- Difficult later extensions.
- Huge amount of code should be written to implement TCP algorithms.
* Will the customer provide us with examples of real data?
- Yes, he will try to provide us with real data, ability to run tcpdump and
gather more information.
* Which is the estimated size of the tcpdump log files?
- For educational purposes not too many events should be used in one
animation.
* Do you have a proposal about the format of the intermediate files between
analyzer and animator?
- This is up to the development groups. ASCII or XML would be better for editing
intermediate files and more readable by humans.
* Should the animator process the data before animating or should it be done
at the same time?
- It depends on the chosen design and the intermediate file format.
* Should the animator show links between layers?
- It would be nice to switch between levels in some way on the fly.
- TCP and IP should be shown and maybe also some application level
information.
* What is the level of detail shown in the animations?
- The user selects the level of detail needed.
- Also IP fragmentation is an optional feature to include in the program,
but the problem it that this data is not present in the tcpdump log files.
* Is it sure that we can syncronize the two traces?
- IP identifiers are useful to find the corresponding packets from different
logs.
- Don't look at timestamps, but use them in the intermediate files.
- Assuming that a teacher is in charge of collecting the log files and
generating intermediate files, and the student only plays animations, the
correction of timestamps is a teacher's task.
- Some problems with old version of Linux can be found in IP identifiers.
The group should assume that IP identifiers are valid.
* In the log file could be present some information about other connections
which are not interesting for us. What should we do with this?
- Use tcpdump to filter unnecessary information.
- It's required to be prepared to get tcpdump files not related with the
animation we want to represent.
* Should we show the reason why a packet is lost?
- From a educational point of view, it is not important. In research, maybe
yes (optional feature).
3.C - Requirements set by the customer in this meeting
(Different types of animations that the customer wants the animator
to be able to show)
* IP layer information presented to user.
- How IP packets are delivered, and what they consist of (address, and some
fields).
- ARP packets: typical internet scenario to resolve addresses and send
packets.
* Transport Layer:
- UDP protocol:
. request, reply, and simple UDP transfer.
. UDP packet that must be fragmented.
- TCP protocol:
. connection establishment.
. sending.
. termination (several ways).
. slow start scenario, with the different ways to end (package loss and
threshold exceeds).
. packet loss.
. fast retransmission and retransmission timeout.
* Application level:
- HTTP:
. simple request and reply.
. small web site retrieval.
. click on link to access a web site with two inline images.
- FTP, SMTP:
. still to decide which (if any) are necessary or optional with Data
Communication teachers.
3.D - Other issues
- The requirements document template is available and may be used to format
the gathered requirements.
- A complete project plan should be ready next week.
3.E - Next meetings
- On Sunday Feb 1st both groups will meet separately and work on the
requirements document. The 2 parts will be integrated on Tuesday Feb 3rd
by the group leaders, before the meeting with the customer.
- The customer asked the requirements document to be sent to him on Monday
Feb 2nd so that he can notify missing parts or errors. Whether this is
possible or not still remains unclear.
- Meeting on Tuesday Feb 3rd at 16h15 with the customer.
4. Action points
- Mr. Brown will take care of the project organization part of the project
plan document.
- Mr. Ananin will take care of CASE tools and SE techniques part of the
project plan document.
- Mr. Fernandez and Mr. Arrastia will take care of monitoring and reporting
mechanisms part of the project plan document, as well as resource
requirements part.
5. End
Mr. Brown ended the meeting at 14:47.
Go back to DaCoPAnDocumentation