Dacopan project MEETING MINUTES
Feb 10th, 2004
Meeting
Feb 10th, 2004, at 16:15
Department of Computer Science, room C475
Attendance
Markku Kojo, client
Alejandro Fernandez Rey
Carlos Arrastia Aparicio
Jari Aarniala, secretary
Jarkko Laine
Jonathan Brown, chairman
Turjo Tuohiniemi, instructor
Vesa Vainio
Andrei Salo
Andrei Ananin
Dmitry Korzun, instructor
Kirill Kulakov
Mikhail Kryshen
1. Start
Mr. Brown started the meeting at 16:15.
2. Assessment of the situation
The list of networking scenarios was updated during the weekend and
sent to the customer on the 9th. The purpose of this meeting was to
gather feedback from the customer about the scenarios and further
dicuss them.
3. Discussion
3.A - Organizational issues
Mr. Tuohiniemi suggested that the forum should be used as the primary
communication channel between (and inside) the groups and that
time-critical issues should be discussed using email.
Project plan needs to be finished ASAP. Requirements analysis needs
to be completed, and the design phase will begin shortly as well.
User interface (animation) issues can be left to the design phase
unless the customer presents some specific requirements during the
requirements analysis.
3.B - Discussion on the scenarios with the customer
Mr. Kojo started with some feedback on the scenarios as a whole and
also focused on each of them individually. He pointed up that in the
scenario document template a clear distinction should be made between
"variables" and "protocol fields". Up until now they've been
referenced to using the common name "variables", which is too vague.
Comments on individual scenarios:
210: It's not required to animate the reassembly of packets if their
order is changed during transportation
310: Mr. Kojo pointed out that UDP layer doesn't fragment packets,
it passes UDP segments of any size to lower layers and it is
eventually the IP layer that'll fragment the packets.
In this scenario, it's not required to handle reordered packets.
321: ISN (initial sequence number) and acknowledgement number are
important, as is MSS (maximum segment size) negotiation.
The SMSS (sender maximum segment size) variable can be
determined from the logs and shown to the user. Port numbers
should also be shown. Later on, a scenario where a client tries
to connect to a non-open port could be added.
322: Postponed, lowest priority
331 and 361:
Merged into one
333: Modify title to "Loss of an early packet".
This scenario should illustrate the case where an early TCP
packet (for example the 2nd) is lost and the congestion window
is not large enough to allow for 3 duplicate ACKs to be
transmitted, thus the TCP fast retransmit mechanism isn't
applicable and the RTO (retransmission timeout) will trigger
a retransmission of the lost packet.
341: Only one side (A) should send data in this scenario, and
handle the closing of the connection as well.
342 and 351:
Postpone
363: Modify title to "Transition from slow start to congestion
avoidance (after RTO recovery)".
411: The HTTP reply should be divided into at least 2 TCP segments,
so it should be large enough.
412: It should be made clear in the description that there are
multiple concurrent TCP connections. An optional
requirement could be to visualize the <img> -tags in the
HTML page that trigger the download of the inline images.
421: This scenario should be about DNS A-record lookups specifically.
In all scenarios, it should be possible to include the TCP states
in the intermediate file, but there's no need to attempt to calculate
the states in the program itself. A simple textbook model of the states
can be used, and the states are only applicable in the connection
establishment and termination scenarios.
Scenarios that involve some more advanced TCP mechanisms (such as
delayed acknowledgements) can be simplified so that the details
that are essential for learning are highlighted, and the more
advanced mechanisms can be left out, as they might confuse students.
Mr. Kojo pointed out that although recent TCP implementations can use
a initial congestion window size of 4 segments (for example), for
the purposes of this program (and the scenarios), a value of 1 (one)
will always be used.
The data for scenarios 321, 361 and 341 will come from the same tcpdump
log that illustrates all of these different scenarios. The same goes
for 201 and 310.
Mr. Vainio suggested that a single list that contains all the
essential variables / fields used in the scenarios should be compiled.
Basically all the fields in the network and transport layer packets
should be supported, so that they can be viewed upon user request.
Also, an initial list of different animation types should be compiled.
3.C - Communication with the customer
Mr. Vainio asked how the communication between the Petrozavodsk group
and Mr. Kojo should be handled from now on. Mr. Kojo said that it
shouldn't have any difference to him whether he's communicating with a
member of the Helsinki group or a member of the Petrozavodsk group: he
will always communicate with the group as a whole.
It was decided that questions that need to be asked from the customer
will either be emailed to him directly and have him answer by email,
or posted on the web forum, and have him answer them in the forum.
Either way can be chosen based on the customer's preference. Mr. Laine
will demonstrate the use of forum to Mr. Kojo on a later date.
4. Action points
- Next meeting with the customer will be on Tuesday, the 17th of
February (yet to be confirmed)
- Mr. Vainio will collect the variables/fields used in the scenarios
to a single list
- Agenda for the next internal meeting of the Helsinki group will
include discussion the animation types and completing the project
plan (size estimate of animator, group schedule)
5. End
Mr. Brown ended the meeting at 18:30
