DaCoPAn Software Engeneering Project

- Home  - Overview  - Members  - Documentation 

- Resources/Links - Project Website

 

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