Dacopan project                                MEETING MINUTES
                                               Feb 6th, 2004

Meeting
   Feb 6th, 2004, at 12:20

   Department of Computer Science


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 12:20


2. Assessment of the situation

   Meeting with the customer to discuss more aspects about the product and
   its requierements.
   For this meeting a set of scenarios have been described and presented to
   the customer to clarify what the program should do in some concrete
   situations that maybe are not trivial.
   A preliminary version of the project schedule has been presented to
   discuss definitive deadlines for the different phases.

3. Discussion

   Preliminary and incomplete version of the scenarios has been given to
   Mr. Kojo to be studied and prioritize scenarios.

    3.A - Scenarios and its template structure:

   Mr. Vaino explains the fields contained in the templates and the reason
   of each of them. These fields are:
   Number of scenario, Name, Implementation priority, Description of
   mechanism, Relevant layers, Educational objective, Variables,
   Pair of tcpdump files, Information to visualize, Program configuration,
   Instructions for user.

   This structure allows to explain what happens in the different layers of
   the communication, explaining the behavior of protocols in them
   separately.

   Some of the fields might be filled in in later stages, as for instance
   the program configuration and instructions for the user fields.

   Tcpdump files should be provided by the customer to complement the
   scenarios approved with real sources.

   The scenarios presented should be grouped by priority and could be 
   dropped depending in how low is its priority. New scenarios could be
   added to the present list if needed.

   3.B - Scenarios presentation.

   - Slow start with packet loss and fast retransmission: This scenario
   could be confusing for the student due to some implicit concepts
   as threshold. It's supposed that the student can check these
   concepts in a text book.
   
   - Drop IP fragmentation in intermediate hosts. Only show two endpoints.
   If a packet is fragmented in a router between the endpoints presented
   the problem is extended to three endpoints and it's out of the scope of
   the project.
   
   - UDP to IP fragmentation. Discard this because the fragmentation in
   the sender is done in the network layer, not in the transport layer.
   Rename this scenario to 'IP fragmentation at sending endpoint'. This
   scenario might include a different representation because the aim of it is
   to show how datagrams are splitted and what happens between layers instead
   of how are they transferred.

   - The scenario UDP packet loss is not relevant.

   3.C - Answers to some questions to the customer.

   - Erroneous checksums in datagrams cause packet drops. The program must show
   the packet loss, but not the reason of that loss. The information about why
   the packet was dropped is not present in tcpdump. Showing the reason of loss
   could be a possible extension for another project.

   - Implicit variables are the ones not present in tcpdump files. Some of
   these implicit variables could be introduced by hand by the user. The customer
   will provide a list of variables that the user could be expected to fill in
   manually into the intermediate file. This feature could be fixed in future
   versions of the product and implicit variables could be calculated by the
   analyzer.

   - The intermediate file should contain all the information present in tcpdump
   files. The information to be shown could be limited by the educator by a
   specific configuration feature. Here the educator can select wich layers are 
   relevant.
   
   - The difference between teacher, researcher and student is only the level of
   detail used for the   animations.
   
   - Information about third part enpoints should be included in the intermediate
   file only for ARP and DNS requests.
   
   3.D - Schedule
   
   A preliminary version of the schedule of the project following the waterfall
   model was presented.
   
   The instructors discussed the schedule and decided that unit testing and
   implementation should overlap. Implementation phase sould be extended until
   few days before the trip to Petrozavodsk. Also a conclusion phase should be
   added at the end of the project.
   
4. Action points

   - More detailed information about the scenarios have to be filled and new
   scenarios added if found. The list of scenarios will be prioritized.
   
   - The schedule have to be fixed due to the new dates decided.
   
   - Next meeting will be on Tuesday February 10th at 16:00.
   
5. End
    
   Mr Brown ended the meeting at 14:35