Dacopan project MEETING MINUTES
Feb 3rd, 2004
Meeting
Feb 3rd, 2004, at 16:15
Department of Computer Science, room C475
Teollisuuskatu 23, Helsinki
Attendance
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
Jari Aarniala
Vesa Vainio, secretary
Turjo Tuohiniemi, instructor
Absent
Nobody was absent
1. Start
Mr. Brown started the meeting at 16:16.
2. Assessment of the situation
This week is a very critical week for the project, as this is the last
whole week that the Petrozavodsk group is in Helsinki. We should try to
complete as many important things as possible before they leave.
3. Discussion
Turjo took and distributed copies of the list of requirements prepared
by the Helsinki group.
3.A - What is missing from the Project Plan
- Schedule
- There should be some fixed milestones
- Writing the schedule should be based on the "Software
Engineering Project - Distributed Approach" document
- size estimate (can be discussed after the division of the work is
decided)
- organization: information of the following should be added
- Supervisor
- Web system
- CVS
- Explanation of member roles to make them clearer
- According to Turjo the Project Plan should be about 30 pages long
3.B Discussion about requirements list with Mr. Kojo
Mr. Kojo disagrees on the requirement "The tcpdump logs given to the
analyzer should contain a single connection only, etc.". This is
because many real life networking situations inherently need multiple
connections. This includes many HTTP requests and also the DNS lookup.
Sometimes multiple connections would be sequential to each other, not
simultaneous. Also, sometimes you may need to distinguish different
connections from each other (by different colors, for example) and
sometimes that is not required. Animating the DNS lookup also presents
another problem, because the DNS lookup goes to a different host than
the actual target of the communication.
Mr. Kojo also pointed out that a term we should be used is "flow"
rather than "connection" because there are no connections in UDP, for
example.
Vesa presented a point that there are different levels of detail that
can be animated. One is close to the detailed mechanisms of protocols
and for that, only a few packets need to be shown at a time, but with
lots of information about them. On a higher level of detail, you are
able to present "emergent" properties of protocols, like reacting to
congestion and network errors. These different levels of protocols
correspond to different educational objectives.
Then it was discussed if the ARP protocol events should be shown. Mr.
Kojo said that it is enough to show functionality of Ethernet (no other
protocols from link layer), that would be enough to show how ARP works.
It was also discussed, if the fact that ARP lookup happened, could be
visualised by a small message box.
Also a scenario where there is incorrect input to the analyser was
discussed. It was concluded that it is preferable for the analyser to
ignore incorrect input rather than exit with error.
Analysing the timestamps was discussed, and if the analyser should
recognize problems with timestamps. Mr. Kojo said that ensuring the
correctness of timestamps is the responsibility of the user. All the
program needs to do is allow the user to input an adjustment that
should be made to timestamps of one host.
Mr. Kojo also disagreed with the requirement "The analyzer should only
be able to analyze TCP connections established within the tcpdump log
file". This would harm the usefulness of the program, because in some
networking scenarios the interesting event only happens quite far in
the connection, and it would be useful to be able to skip the
non-interesting information at the beginning.
Mr. Kojo suggested that the analyzer should dynamically keep track of
all the flows it encounters in the log files. Every time the analyzer
encounters the beginning of a previously unseen flow, it should just
add it to its internal list of flows. This should technically be easy
and not burden the implementation.
Mr. Kojo said that the program should support the following application
level protocols: 1. HTTP 2. DNS 3. IP fragmentation with any UDP
protocol.
Mr. Kojo said that he doesn't require the program to be able to animate
anything backwards. It's enough for the user to be able to spesify a
point in the animation where he wants to step (in one step), and this
point can be in the backward direction, but it is enough for the actual
animation to always proceed forwards. Vesa agreed that this is
educationally feasible.
It was agreed that the specification of 'an animation step' should be
decided later. Steps can be either a time tick or a packet
sent/received. It's probable that the program should support both, and
let the user configure the choice.
Vesa commented on the requirement "The user should be able to view
detailed (relevant) information on a packet by clicking it". He pointed
out that from educationalp oint of view all relevant information should
be visible at once. The user should be able to do this by configuring
the view. Otherwise the learner would need to keep too much information
in his memory, and this is not good for learning. Mr. Kojo pointed out
that the learner may reach an advanced stage where he may want to go
investigating detailed information about packets to understand the
mechanisms better, and it would not be possible that all information be
kept visible anyway.
Kirill asked about the definition of IP protocol, does it mean IPv4 or
IPv6. Mr. Kojo said that the program only needs to work with IPv4 at
this stage, but the intermediate file format should be extendable to
IPv6.
3.C Discussion about animating packet encapsulation in different levels
Mr. Kojo said that it is mandatory that the program should be able to
visualize the encapsulation of information for the different layers.
Mr. Kojo explained that the 'conservative' way of visualising
encapsulation is so that the packet is drawn horizontally and the time
goes from up to down. On each successive layer the packet from above
layer is included as the payload for the lower layer, and the template
of the protocol header is filled in with appropriate information. Mr.
Kojo does not absolutely require that this process is animated, it is
possible that it may be presented as a static diagram.
3.D Discussion about List of Scenarios
The list of networking scenarios that the program should be able to
animate was found to be extremely relevant at this stage, and this
list, with complete descriptions, should be produced as soon as
possible.
This list of scenarios put together defines the extent of animation
abilities that are required of the program.
Also, this list of scenarios defines the educational objectives of the
program. The educational objectives are that students should be able to
learn to understand the mechanisms depicted by the scenarios.
Mr. Kojo said that he will try to produce tcpdump logs corresponding to
the scenarios as soon as he gets the list in writing. We will review
the list of scenarios in the Tuesday 10th of February meeting. At that
meeting, Mr. Kojo would give presentations about the mechanisms
involved in the scenarios to make sure all members of the project
understand them. For this Mr. Kojo needs to receive the list from us
by noon on Monday 9th Feb, so that he has time to read them.
Mr. Kojo also wanted to add two scenarios to the ones that have been
discussed previously. These are:
1. DNS lookup.
2. application data not fitting in one TCP or UDP segment and needing
to be fragmented.
If it's not possible to get the presentations from Mr. Kojo on Tue 10th
Feb, then it is possible for the Petrozavodsk group to get
presentations from a local expert.
Mr. Kojo also recommended a book named TCP/IP Illustrated Volume 1 by
Stevens if we need to learn more about the protocols.
3.E This Week's Agenda
- start design
- diary: Turjo told us that we should start keeping personal diaries
about the project. We should include our understanding about the
project status, our own experiences, our views of how others work, etc.
This diary would be personal and private during the project. At the end
of the project they would be read by the course administrators and used
as course feedback.
The Helsinki group can write their diaries in Finnish or in English and
the Petrozavodsk group can probably write theirs in Russian if they
wish.
Turjo also requested that everybody keep their diaries in the group
resource and put the access rights so that others can't read them. This
way Turjo will be able to watch the file sizes grow.
- progress report
- progress reports should be put by everyone to the project
resource by Tuesday this week
- it was decided that we will use only full hours
- the file should be named like FirstnameLastname.txt
- reports from groups need to go to different directories
- reports from both groups will be sent to both supervisors
- preparing and sending the reports is the task of the group
leader
- Vesa will prepare a proposal for different task types that we
should use when marking the hours. Turjo will modify the
script so that it will produce neat reports from this
information.
- division of the project between the groups: It was agreed that the
Petrozavodsk group will work on the analyzer and the Helsinki group
will work on the animator.
The intermediate file format is an important interface between the two
major software modules and because of this the groups need to
co-operate on designing the file format.
The file format is most likely to be XML based.
The animator group will produce requirements on what information should
be present in the intermediate file.
If the workload for the project seems to be unevenly distributed
between the groups, then methods to even out the workload will be
discussed. Having a member of one group work mainly with the other
group has good and bad sides. The bad side is that it may create a
bottleneck of communication and thus increase risk of failure for a
particular component. The good side is that it increases the overall
communication between the groups and thus gives both groups better
understanding on what is going on at the other group. This reduces
overall risk of misunderstandings.
It was discussed if the analyzer module should include information
about implicit variables to the intermediate file. (Explicit variables
are those that can be explicitly read from tcpdump logs. Implicit are
those that need to be inferred, produced by simulation, etc.) From an
educational point of view it would be extremely important to show the
user information about host states, and this information is mostly in
implicit variables. Previous discussions with the customer show that he
will want the program to work on implicit variables. However, this will
need to be discussed with the customer in more detail.
- list of scenarios
- Vesa wasn't present when the scenarios were discussed for the first
time. He wants to participate in preparing the list, but he can't take
part in the first writing of the draft.
- Carlos, Alex, Mikhail, Vesa and Jari will work together on the list.
- project plan
- schedule (Kirill, Jonathan)
- risk analysis (Jari)
- Helsinki local organization (Jari)
- size estimation based on division of project
- rules for editing documents
- some rules (and the necessity of such rules) for editing
documents was discussed
- the following rules were mentioned:
1. Inform other members of the project before making a major
edit to a document.
2. Before making significant changes to someone else's text,
ask this person first to make sure you understand what the
other person meant by his text.
- misc
- Petrozavodsk minutes to TWiki
- Viktor Surikov is a new member of the Petrozavodsk group
3.F Next meeting
Next global meeting (both groups, without the Customer) will be held at
the CS department room C475 on Thursday 5th February 2004 at 8:15am.
4. Action points
- List of scenarios for Mr. Kojo by Monday (9th Feb) noon (Carlos,
Alex, Mikhail, Vesa, Jari)
- Proposal about project 'task types' (Vesa)
- Kirill and Jonathan will produce a draft of the schedule for project
plan
- Discuss information on implicit variables with the customer
- Files for progress reports to the group folder by Tuesday from
everyone
- Jari will work on Risk analysis and Helsinki local organization parts
for the Project Plan
5. End
Mr. Brown ended the meeting at 19:35.
Go back to DaCoPAnDocumentation