Dacopan project                                MEETING MINUTES
                                               Feb 1st, 2004

Meeting
        Feb 1st, 2004, at 13:30

        Department of Computer Science

Attendance
        Alejandro Fernandez Rey
        Carlos Arrastia Aparicio
        Jari Aarniala, secretary
        Jarkko Laine
        Jonathan Brown, chairman
        
Absent
        Vesa Vainio

1. Start
        Mr. Brown started the meeting at 13:30.

2. Assessment of the situation
        An initial list of requirements for the software is needed as soon as
        possible.

3. Discussion
        The minutes of the two meetings with the client along with the
        requirement list received from him were used as the basis for this
        requirements elicitation session. Lengthy discussions about many
        of the requirements from the client were held and as a result, an
        initial list of requirements was created. (See the list at the end
        of this memo).
        
        As for the original requirements listed by the client, the group found
        the requirement for ARP support to be rather confusing, as ARP operates
        on the link level and only three network levels have been discussed
        before (application, transport and network level). ARP would clearly
        not fit into any of these three layers.
        
4. Action points
        - At the next meeting, ask about ARP support from the customer.
        - Hold another requirements elicitation session with the group from
          Petrozavodsk, request comments from them

5. End
        Mr. Brown ended the meeting at 17:15.
        
        
--

Appendix: initial requirements list, grouped into two categories based on the
          assumption that two separate components, Analyzer and Visualizer
          will be created

* Analyzer:

- The analyzer requires two tcpdump log files from two different endpoints as input.
  These logs should contain only the protocol exchange between the two endpoints:
  any other traffic should be filtered out by the user before passing the data
  into the analyzer
- The tcpdump logs given to the analyzer should contain a single connection only,
  so filtering unwanted connections out of the logs should be done by the user
  of the analyzer (by using tcpdump filters, for example)
- The analyzer needs to produce explicit information about the protocol exchange
  so that the animator doesn't need to know about protocol specifics, such as
  TCP states etc - these should all be present in the intermediate file created
  by the analyzer
- The analyzer should only be able to analyze TCP connections established within
  the tcpdump log file
- The analyzer should support HTTP (TODO: others?) on the application layer, TCP
  and UDP on the transport layer and IP on the network layer
- If the order of the protocol exchange can't be determined without knowing the
  time difference of the two logs (this is the case with UDP, for example) the
  user must enter the difference manually, otherwise the analyzer should exit
  with an error.
- Also, whenever the time difference of the logs is given to the analyzer,
  the delays between the messages should be included in the intermediate file

* Animator:

- The user should be able to start and pause the animation
- The user should be able to rewind and forward the animation (i.e. jump to packet #2)
- The user should be able to step forward / step back in the animation
- The user should be able to select the speed of the animation
- The user should be able to specify breakpoints in the animation, i.e. specific
  times when the animation automatically pauses

- The author of the presentation should be able to add notes (comments) to the
  presentation

- The user should be able to select the level of detail for the animation
- These settings can be saved and later loaded into the program.
  
- The user should be able to select a specific layer (application, transport or network)
  for viewing on the fly
- The visualizer will be able to visualize only one transport level connection at a time:
  this implies one connection on application level as well

- The user should be able to view detailed (relevant) information on a packet by clicking it
- Relevant information of both endpoints should be shown upon user request. This
  includes port number, ip address, hostname etc
  
- If information on the delays between the packets is present in the
  intermediate file created by the analyzer, an option should be available to
  visualize the delays

---

Back to DaCoPAnDocumentation