Session S2F
Collaborative Learning Strategies and Scenario-based Activities for Understanding Network Protocols Davinia Hernández, Juan I. Asensio, and Yannis A. Dimitriadis School of Telecommunications Engineering, University of Valladolid, Camino del Cementerio s/n, 47011 Valladolid, Spain,
[email protected],
[email protected],
[email protected] Abstract - This paper details the experience of using both scenario-based and collaborative approaches in a test laboratory for the understanding of several Transmission Control Protocol (TCP) mechanisms. Through the analysis of potential differences in expected and real behavior of those mechanisms in a set of pre-defined scenarios of real TCP traffic interchange, students are expected to detect misunderstandings and, even more interestingly, to design their own new scenarios for further clarification. Simultaneously, students are arranged in groups that collaborate, with the help of supporting computational tools, following a predefined activity sequence that is designed according to commonly used strategies in collaborative learning. Those collaborative strategies are selected so as to foster group work as well as to share the work load among group members without precluding student’s comprehension of the whole set of TCP mechanisms. The combination of both the scenario-based and collaborative approaches also contributes to the acquisition of desirable skills linked to general competencies of engineers: scenario analysis/design, interpretation, communication, argumentation, discussion, etc. The paper details the sequence of student activities, justifies the use of collaborative strategies, describes the computational support for collaborative activities, and finally provides evaluation results of this real experience as well as the resulting findings and lessons learned. Index Terms – Computer-supported collaborative learning, Network protocols education, Scenario-based learning INTRODUCTION Several approaches for teaching computer network protocols concepts and mechanisms by means of lab exercises and projects have been reported in the literature. Significant examples include the use of networking tools (traffic monitors, traffic analyzers, etc.) in real scenarios [1], the use of network simulators [2], protocol implementation and network programming project-based activities [3], and even the performing of learning activities with no computer and network support at all [4]. This paper reports an experience carried out in an undergraduate course on computer network protocols that combines several of those approaches: networking tools in real scenarios, network programming, and simulation. The course belongs to the studies of “Telecommunication Engineering” at
the University of Valladolid, Spain. More particularly, the paper focuses on the lab exercises related to the first of the mentioned approaches: the use of networking tools in real scenarios of traffic interchange for the learning of, in this particular case, concepts and mechanisms of the Transmission Control Protocol (TCP): the connection-oriented and reliable transport-level option of the TCP/IP protocol suite [1]. During previous years, those lab exercises simply comprised the analysis of the traffic that communicating applications running in lab hosts interchanged among each other (or with applications running in other Internet hosts) through the lab network. The set of communicating applications included, in a similar way as proposed by [1], common client/server utilities (FTP, telnet, web,...) as well as user-configurable traffic sources and sinks based on the sock application [1]. The students were requested to set up the applications in a predefined way, to capture the traffic with the tcpdump tool [5], and to analyze captured traffic identifying what TCP mechanisms previously explained in theoretical lecturers were involved (connection establishment, flow control, slow start, congestion avoidance, Nagle algorithm, etc.) Seeing the protocols “in action” enabled the students to contrast their knowledge of the protocol mechanisms with their real behavior thus detecting potential misunderstandings. Nevertheless, this approach showed to have several weaknesses. Firstly, the large set of TCP mechanisms under study demanded from the students the setting up of an also large set of traffic interchange scenarios. Therefore the students’ effort was devoted, to an important extent, to the performing of those repetitive configuration tasks. This fact precluded them from focusing on the understanding of the protocols mechanisms themselves and the circumstances under they are intended to be useful. Secondly, the time required for the analysis of a large set of scenarios involving single mechanisms made difficult (within the time frame of the course under study) to devote time for the setting up and analysis of scenarios implicating a combination of several TCP mechanisms simultaneously. This fact hindered the understanding of the mutual influence among TCP mechanisms and, consequently, their differences and purposes. With the goal of alleviating those problems, the paper reports an improved experience in which students were encouraged: • To design (not only analyze) their own scenarios of traffic interchange that trigger one or a combination of TCP mechanisms. This kind of scenario-design activities helped
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-19
Session S2F •
the students to understand the circumstances under a TCP mechanism is intended to be useful, To collaborate in groups with other students so as to complete traffic analysis and scenarios design tasks. By means of collaborative activities, students were expected to generate further knowledge as well as to share the work load, thus providing new time slots for introducing new exercises.
In addition to the above advantages, basically related to the course contents and organization, the kind of scenario-based and collaborative activities introduced in the course generated opportunities for the students’ acquisition of competencies and skills such as argumentation capacity, responsibility for the own learning, involvement in group work, etc. Therefore, the paper firstly introduces the course that constitutes the context of the reported experience. Then it details its educational design, focusing on the type of scenariobased and collaborative activities proposed to the students. Also, the paper justifies those activities according to the goals of the course with respect to both contents and competencies and skills that the students are intended to acquire. Afterwards, the paper devotes a section to the explanation of how the experience has been evaluated and what conclusions can be drawn from the evaluation results. Finally, the paper presents some conclusions and details some future lines of actuation. COURSE BACKGROUND The experience reported in this paper takes place in an undergraduate course on computer network protocols. It is placed in the fall semester of the third year (out of five) of the studies for achieving the degree of “Telecommunications Engineering” at the University of Valladolid, Spain. It is the third out of five courses belonging to the core body of knowledge of the degree’s curriculum that are devoted to the study of computer network protocols following a bottom-up layered approach. The first of those courses introduces basic concepts of computer networks and focuses its attention on media access control and logical link layer techniques and protocols. The second course is mainly devoted to network layer aspects (routing, congestion control, etc.). Finally, the third course, the focus of this paper, deals with transport-level protocols and, specifically, with the Transmission Control Protocol (TCP). The remaining two courses cover applicationlevel protocols. The course spans a 15-week-long semester and involves 30 lecture hours (one two-hour session per week) and 60 laboratory hours (two two-hour sessions per week). The 60 laboratory hours are divided in three different types of exercises: 22 hours involve exercises of analysis and design of scenarios of traffic interchange, 22 hours are devoted to network programming with the BSD sockets API [6], and the last 16 hours propose activities based on the use of the ns-2 [7] network simulator. The paper is focused on the activities performed during the first 22 hours. 160 students participate in the course approximately. Due to physical space restrictions at the lab, they are divided in 4
groups of 40 students. Consequently, each lab session is repeated 4 times a week. The lab consists of 25 Intel Pentium IV-class machines running Linux 2.6.8. The students are arranged in group of two that share the same lab resources (machine, user account, etc.) and work together during the whole course (in what we call a “basic group”). EDUCATIONAL PROJECT I. Scenario-based lab activities Scenario-based learning is defined as “...learning that occurs in a context, situation, or social framework. It’s based on the concept of situated cognition, which is the idea that knowledge can’t be known or fully understood independent of its context” [8]. Applying this same idea, knowledge on computer network protocols cannot be fully understood if it is not situated in the context in which those protocols are used: applications that communicate through a computer network. Within this context, students are requested to perform two types of activities: analysis of predefined scenarios of traffic interchange (provided by the teachers) and design of new scenarios that illustrate a required set of protocol mechanisms. Analysis activities enable the students to confront real protocol behavior with the knowledge acquired in theoretical lecturers (thus detecting potential misunderstandings). Design activities “force” the students to focus their attention in the circumstances under which a particular mechanism is useful. This helps the students to differentiate the protocol mechanisms and promotes a better understanding. Table 1 enumerates the TCP mechanisms to study during the 22 first lab hours of the course as well as the type of scenarios that the students are requested to analyze and to design. The enumerated TCP mechanisms are grouped in “sets” (left-hand column) related to the collaborative activities that will be described in the following section. TABLE 1 TCP MECHANISMS [1] TO BE STUDIED IN THE COURSE AND THE RELATED SCENARIOS OF TRAFFIC INTERCHANGE TO BE ANALYZED AND/OR DESIGNED Set TCP Scenarios Mechanism Common TCP Analysis: telnet session with a “local” machine connection and web session with a “remote” machine. establishment and termination TCP HalfDesign: use of sock tool as traffic source and close sink with options needed to “force” a half-close scenario. TCP Reset segments
A
Analysis: telnet session with “unreachable” TCP port.
Retransmission Design: scenario of retransmission during time-out (error connection establishment (e.g. disconnecting control) network cable). Design: scenario of ARP (Address Resolution Protocol) traffic capturing during TCP connection establishment (due to expiration of ARP cache)
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-20
Session S2F
B
C
D
Combined
2MSL (Maximum Segment Lifetime) timeout (error control) Nagle algorithm (reduction of protocol overhead caused by small TCP segments)
Analysis: scenarios proposed in [1] for the measurement and characterization of the 2MSL time-out.
Analysis: telnet session in which a sentence is typed (impossible to identify the mechanism due to human key pressing rhythm.) Analysis: telnet session in which the same typed sentence as above is “copied and pasted” at once (the Nagle algorithm can now be identified.) Design: use of sock tool so as to illustrate Nagle algorithm behavior (fast generation of small data chunks that will be grouped by the mechanism.) Analysis: identification of the “delayed ack” mechanism and its positive/negative influence in the Nagle algorithm (ack delaying enables Nagle algorithm to generate larger segments thus reducing protocol overhead.) Sliding Design: using the sock tool, a traffic source Window (flow requests TCP to send a large chunk of data. A control) traffic sink “reads” data from TCP in smaller chunks. It is interesting to analyze the size of the advertised sliding windows of the TCP receiving entity when the buffer size is modified, when “read” operations are separated by a certain amount of time, when those operations start a certain amount of time after the connection is established, etc. (the flow control imposed by the sliding windows is observed as well as its relationship with the receiver’s buffer size.) Design: the above scenario is requested to be analyzed again but running the traffic sink in a Sun Sparc workstation using Solaris operating system (in order to discover different TCP behavior in different implementations.) Slow start and Analysis: using the sock tool, a traffic source congestion and a traffic sink interchange TCP data within window the lab network (the slow start mechanism is (congestion difficult to appreciate due to low delays). control) Design: use of sock tool as traffic source in order to illustrate the slow start mechanism behavior (e.g. using a “remote” web server as traffic sink. The mechanism can be appreciated if delays are long enough). This scenario is useful to illustrate under which circumstances the congestion window decreases the traffic sending rate. Design: the above scenario is requested to be analyzed again but running the traffic source in a Sun Sparc workstation using Solaris operating system (in order to discover different TCP behavior in different implementations.) CongestionDesign: identify which of the two mechanisms window vs. limit the data sending rate and under which sliding window conditions Nagle Design: identify which of the two mechanisms algorithm vs. force the traffic source to interrupt the sending sliding window of data using as the traffic sink a “far” (in terms of end-to-end delay) web server Retransmission Design: scenario of retransmission during the time-out vs. data transfer phase of a TCP connection ARP time-out between two machines located in different networks (not within the lab network, in order to analyze the differences.)
II. Collaborative lab activities and supporting tools Collaborative learning [9] is a process in which participants acquire new skills and build new knowledge by means of the interactions that take place within the members of a group. This pedagogical approach can be considered to be more effective than individual and competitive learning under many circumstances [10]. In some contexts, collaborative learning can benefit from the support of computational and/or networking tools. Computer-Supported Collaborative Learning (CSCL) is the research field that, within the broader scope of technology-enhanced learning, deals with the computational support of collaborative interactions that take place during collaborative learning activities. Nevertheless, collaboration does not always happen spontaneously, and when it happens, it does not always generate learning in an effective way [11]. Therefore, when collaborative learning wants to be introduced in an educational project, it has to be planned in such a way that it fosters effective interactions among students. There are several wellknown techniques for structuring collaboration that have repetitively proved to generate effective learning [12]. In fact, those techniques can also be considered as “patterns” (recurrent solutions for recurrent problems) for structuring collaboration [13]. Their application to the context of one particular educational project may contribute to alleviate the risk that is always present when designing a collaborative learning experience. In the course described in this paper, two collaborative learning techniques have been applied: jigsaw, and pyramid. Both techniques are described in Table 2 indicating the context in which they can be applied, what they propose, and the educational benefits they promote. The overall structuring of the lab work has been based on the jigsaw technique, as it is useful in the context of the course under study: “complex problem/task that can be easily divided into sections or independent sub-problems”. That structuring is detailed in Table 3. TABLE 2 DESCRIPTION OF THE COLLABORATIVE LEARNING TECHNIQUES APPLIED TO THE EDUCATIONAL PROJECT
Context
Proposal
Jigsaw Pyramid Complex problem/task that can be Complex problem, usually easily divided into sections or without a concrete solution, independent sub-problems. whose resolution implies the achievement of gradual consensus among all the participants. Each participant (individual or Each individual participant initial group) in a group (Jigsaw studies the problem and Group ) studies or work around a proposes a solution. Groups particular sub-problem. The (usually pairs) of participants of different groups that participants compare and study the same problem meet in an discuss their proposals and, Expert Group for exchanging finally, propose a new ideas. These temporary focus shared solution. Those groups become experts in the groups join in larger groups section of the problem given to in order to generate new them. At last, participants of each agreed proposal. At the end, Jigsaw group meet to contribute all the participants must with their expertise in order to propose a final and agreed solve the whole problem. solution.
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-21
Session S2F Benefits
•
• •
To promote the feeling that team members need each other to succeed (positive interdependence). To foster discussion in order to construct students’ knowledge. To ensure that students must contribute their fare share (individual accountability.)
•
•
To promote the feeling that team members need each other to succeed (positive interdependence.) To foster discussion in order to construct students’ knowledge.
As it can be appreciated in Table 3, “basic groups” (two students) devote four two-hour sessions to work on the set of TCP mechanisms labeled in Table 1 as “common”. These are introductory activities in which students get familiar with the lab context and tools. Then collaboration begins. Four “basic groups” join in a jigsaw group (we also call it “super-group”). Each “basic group” is assigned a set of TCP mechanisms to study (A, B, C, or D set in Table 1). Therefore, in each session lab there are five “super-groups” whose four “basic groups” will initially work on its assigned set of TCP mechanisms during three lab sessions. Then, “basic groups” that are “experts” in the same set of mechanisms work together during session #9. At last, “super-groups” join again in order to collaborate with the final goal of having a common understanding of all TCP mechanisms: first of all, each “expert” group explains to the others the mechanisms it has studied; then, the whole “super-group” works on a set of scenarios in which a combination of several TCP mechanisms actuate simultaneously (“combined scenarios” in Table 1). This last phase is structured according to the pyramid technique (very useful for facilitating consensus achievement): initially, “basic-groups” work alone and, afterwards, they all discuss on their corresponding results and agree on a set of common conclusions. Table 3 also details the expected outcomes produced by the students: three written documents and reports as well as the answering of two questionnaires. TABLE 3 SEQUENCE OF LAB SESSION AND THE CORRESPONDING INDIVIDUAL AND COLLABORATIVE LEARNING ACTIVITES
Sessi on 1 2 3 4 5
Activity description
Outcome
Jigsaw phase: “individual work” All “basic groups” (two students) works on the common set of TCP mechanisms Each “basic group” works on the assigned set of TCP mechanisms (A, B, C, or D)
None to deliver
6
Collaboration support tools None
Questionnaire on the Quest tool common and assigned set of TCP mechanisms (at the end of session #7)
7
8
Discussion on the test results moderated by the teacher
Written report on the assigned set of TCP mechanisms (eightpage document to be finished a week before session #10) List of controversial points to be discussed with other “experts”
BSCW tool to store, share, and comment the reports None
9
10
11
Jigsaw phase: “experts work” “Basic groups” that have worked on the same set of TCP mechanisms (“experts”) meet together and discuss on the test results and controversial aspects (generated during the discussion) Jigsaw phase: “jigsaw work” (I) Each “basic group” in a “super group” explains to the others the mechanisms of its assigned set. Prerequisite: each “basic group” has read the written report of the other members of the “supergroup” Jigsaw phase: “jigsaw work” (II) Analysis of “combined scenarios” according to a “pyramid” structure: Pyramid level 1 Each “basic group” works individually Pyramid level 2 The whole “super group” compares and discusses the obtained results and tries to obtain a common consensus
Document with a list of discussed topics and agreed conclusions (onepage document delivered at the end of the session)
BSCW tool to store, share, and comment the list of discussed topics and agreed conclusions
None to deliver
BSCW tool for accessing the reports of the rest of “super group” members.
At the beginning of Quest tool session #12 students answer a questionnaire individually. The questionnaire contains 4 questions on each set of mechanisms (A, B, C, and D) as well as 4 questions related to the relationships among different mechanisms
For supporting all the collaborative activities and the generation of their expected outcomes, two CSCL tools were employed: the Basic Support for Cooperative Work (BSCW) [14] and Quest [15]. BSCW encourages and assists collaboration by providing the students with a shared webbased document repository. Also it offers additional features for handling shared documents such as a commenting tool (one student may “post” comments on another’s document), and an awareness tool (it informs students by e-mail about the uploading of new documents, their modification, etc.), among others. Quest is a web-based tool that provides support for questionnaire edition and answering. Questionnaires are used for posing questions about the TCP mechanisms to the students. The obtained answers are also used for structuring a discussion that takes place in session #8. That discussion aims at clarifying detected misunderstandings and to generate new questions on the TCP mechanisms intended to motivate further work and collaboration. It is also worth mentioning, that students were involved, at the beginning of the course, on the decision on how to grade the outcomes generated during the 22 hours of lab work, as well as in the decision on how to form “super-groups” and how to assign mechanisms sets to each “basic group”. This involvement is based on a learning technique call “learning contracts” [16]. This technique defends that by negotiating with the students different organizational issues, they try to better understand the course plan and also show a higher implication in the course development.
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-22
Session S2F III. Main expected competencies and skills
organization, collaboration.
The use of scenario-based and collaborative learning should foster the acquisition by students of an important set of desirable competencies and skills. The most important of them are enumerated in Table 4. Those competencies and skills are aligned with the prescriptions of the educational guidelines of the future European Higher-Education Space [17]. TABLE 4 MAIN EXPECTED COMPETENCIES AND SKILLS Competencies Skills Pedagogical Method Thinking and -Argument building Scenario-based analysis arguing design Collaboration (pyramid) Problem solving -Situation analysis Scenario-based analysis and planning -Experiments design design design Responsibility -Plan and guide own Collaboration (pyramid for the own learning jigsaw) learning -Understand, take part in, and be sensible to others’ contributions -Work collaboratively Working with -Information selection Collaboration (jigsaw) large amount of -Data observation and Scenario-based analysis information interpretation design Communication -Explain ideas to others Collaboration (pyramid jigsaw)
Collaboration observations
BSCW logs
Registration of interactions among students by teachers during collaborative activities as well as their qualitative annotation Access to shared documents (for reading, annotation, modification, etc.)
Identification of expected and non-expected modes of interactions among students. Quantification of information interchange among collaborating groups
II. Results and Discussion and and and
and and
EVALUATION OF THE PROJECT I. Evaluation Methodology The experience described in this paper has taken place in the fall semester of 2005. Two teachers were involved in both the lecturers and lab sessions. Evaluating the success of an experience such as the one reported in this paper is a complex task due to the nature of the factors that must be taken into account, some of them not easily quantifiable: individual characteristics of learners and educators, social issues, impact of technology environment, etc. Therefore, the mixed evaluation approach based on that proposed in [18], that combines quantitative and qualitative evaluation methods, has been selected for that purpose. Quantitative methods allow detection of general trends related to students’ opinions and attitudes, while qualitative methods allow the evaluator to understand these trends better by introducing context issues and considering participants’ perspective [19]. Table 5 briefly explains the nature and purpose of the data sources that provide input information for the evaluation of the project. Data collection and processing is supported by a set of computational tools: questionnaires are edited and answered by means of the Quest tool; and analysis of qualitative explanations contained in questionnaires is supported by the NudIST [20] tool. TABLE 5 DESCRIPTION OF THE DATA SOURCES FOR THE EVALUATION OF THE PROJECT Source Type of Data Purpose Questionnaire at Quantitative ratings and Collection of students’ the end of the qualitative explanations on opinion on the experience: experience those ratings context, resources,
This section will be structured according to the questions posed to the students at the end of the experience. The answers to those questions (both quantitative and qualitative) provide some useful indications for drawing preliminary conclusions on the success or failure of the experience. The discussion on those indicators and the corresponding conclusions is enriched with data coming from the other data sources enumerated in Table 5. Some relevant conclusions as well as the supporting evidences provided by evaluation data are summarized in Table 6. TABLE 6 SUMMARY OF RELEVANT EVALUATION CONCLUSIONS AND EVIDENCES Aspect of Preliminary Evidence interest conclusion Structure of The structure of the Only 6% of the students have a the experience is negative opinion on the way the experience perceived as a experience has been structured, e.g.: positive aspect in “working with other groups has derived general, specially in the raising of many doubts. I do not the introduction of like depending on others’ work”. collaborative Oppositely, most of the answers activities. emphasize positive aspects of the structuring, e.g.: “working in supergroups is new, interesting, and funny”, “it is easier to understand certain TCP concepts when they are explained by experts on them”, “explaining something to your classmates demonstrates whether you understood it or not”, “it has reduced the work load”... Collaboration The experience has Observations (see Table 5) show that been successful in students have collaborated following promoting teachers’ instructions with slight collaboration. differences in the time each group devoted to the activities of session #10, and #11. BSCW logs have shown that before session #10 all documents had been read at least 4 times by different groups (all “basic-groups” had read the reports written by the other members of the same “super-group”). Some of the reports had been read up to 10 times by different groups. Students consider Students were asked on the advantages that collaboration and drawbacks of introducing provides important collaborative activities in the advantages, experience. Among advantages, although it requires students indicated: “it is more a greater effort and motivating than just listening to a creates doubts on teacher’s explanation”, “it helps to the “correctness” of understand how important is to prepare what students have your part properly so as to help your learnt. group mates”, “it reduces competitiveness”, “it is good for real life”. Negative opinions include mostly
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-23
Session S2F Computational support of collaborative activities is adequate. Competencies The experience has and skills “forced” the students to reach consensus, to discuss/listen with/to others, to build arguments, and to be responsible for their own learning.
variations of “common doubts cannot be solved”, and “it requires more effort and time”. Students were requested to grade (in the range 0-10) the importance of BSCW and Quest tools for their work. Quest received an average of 6.77 (deviation of 1.57) and BSCW an average of 7.86 (deviation of 1.86). Students were asked to enumerate what skills were required in order to complete the proposed tasks. The above skills were the most cited.
As a last interesting evidence found in evaluation data it is worth mentioning that many students showed their concern with the fact that becoming “experts” in a subject (as dictated by the jigsaw technique) might imply less knowledge in the other subjects. Nevertheless, when processing the results of the questionnaire that the students individually answered at the end of the experience (see Table 3) in the range 0-10, the overall variance was only 1.72. Furthermore, if we analyze the results of the questionnaire obtained by each type of “expert”, and taking into account that the questionnaire included four questions on each of the TCP mechanisms set (A, B, C, D, as well as four questions on the “combined” scenarios), the number of failures corresponding to each group of questions was quite similar. More concretely, the variance among the average number of wrong answers (range of 0-4), calculated for each group of questions and for each type of “expert” was always lower than 0.06. These results provide indications that collaboration was effective and that apparent problems of the jigsaw technique were minimized
ACKNOWLEDGMENT This work has been partially funded by the e-Learning project EAC/61/03/GR009, Kaleidoscope NoE FP6-2002-IST507838, Spanish Ministry of Education and Science projects TIC-2002-04258-C03-02 and TSI2005-08225-C07-04 and Autonomous Government of Castilla y León, Spain, projects VA009A05, UV46/04 and UV31/04. REFERENCES [1] [2]
[3]
[4] [5] [6] [7] [8] [9] [10] [11]
[12]
CONCLUSIONS AND FUTURE WORK This paper has presented an experience for the learning of the TCP protocol that takes advantage of scenario-based and collaborative approaches. Preliminary evaluation results provide indications on that these approaches contribute to a better understanding of the applicability of the mechanisms, to a sharing of the workload, and to the fostering of important competencies and skills for engineers. Also, the chosen collaboration techniques for structuring the experience seem to have fostered collaboration in an effective way. Nevertheless, students have also pointed out the fact that this kind of experience implies a different way of working (possibly requiring from them more implication and a higher level of dedication) and that sharing “expertise” may sometimes produce the feeling that some concepts have not been understood properly. The reported experience has been carried out in just a single opportunity and the authors realize that the obtained evaluation results should be considered of limited applicability. Nevertheless, these preliminary conclusions indicate that it is worth continuing the experience in following years.
[13]
[14] [15]
[16] [17] [18]
[19]
[20]
Stevens, W. R. "TCP/IP Illustrated vol. 1: the protocols", AddisonWesley, 1995. Al-Holou, N. , Booth, K. K., and Yaprak, E., "Using Computer Network Simulation Tools as Supplements to Computer Network Curriculum", 30th ASEE/IEEE Frontiers in Education Conference, Kansas City, MO, USA, Oct. 2000, pp. S2C-13-S2C/16. El-Kharashi, M. W., Darling, G., Marykuca, B., and Shoja, G. C., "Understanding and Implementing Computer Network Protocols Through a Lab Project", IEEE Transactions on Education, vol. 45, no. 3, Aug. 2002, pp. 276-284. Surma, D. R. , "Lab Exercises and Learning Activities for Courses in Computer Networks", 33rd ASEE/IEEE Frontiers in Education Conference, Bouder, CO, USA, Nov. 2003, pp. T2C-21-T2C/25. Tcpdump, http://www.tcpdump.org, last visited: Mar. 2006. Stevens, W. R. "Unix Network Programming vol. 1: Networking APIs: Sockets and XTI", Prentice-Hall, 2nd ed., 1998. The Network Simulator ns-2, http://nsnam.isi.edu/nsnam/index.php/User_Information, last visited: Mar. 2006. Kindley, R. W., "Scenario-Based E-learning: A Step Beyond Tradicional E-Learning", ASDT online magazine - Learning Circuits, vol. 3, no. 5, May 2002. Dillenbourg, P. (Ed.) "Collaborative Learning: Cognitive and Computational Approaches", Elsevier Science, 1999. Johnson, D. W. and Johnson, R. T. "Learning together and alone: cooperative, competitive, and individualistic learning", Allyn and Bacon, 5 ed., 1999. Dillenbourg, P. Over-scriptings CSCL: the risks of blending collaborative learning with instructional design. In: Three Worlds of CSCL. Can we support CSCL?, ed. Kirshner, P. A. Heerlen: Open Universiteit Nederland, 2002, pp. 61-91. Doing CL: CL Structures, http://www.wcer.wisc.edu/nise/cl1/CL/doingcl/clstruc.htm, last visited: Mar. 2006. Hernández-Leo, D., Asensio-Pérez, J. I., and Dimitriadis, Y., "Computational representation of Collaborative Learning Flow Patterns using IMS Learning Design ", Educational Technology & Society, vol. 8, no. 3, Oct. 2005, pp. 75-89. Basic Support for Cooperative Work (BSCW), http://www.orbiteam.de/en/index.html, last visited: Mar. 2006. Gómez, E., Rubia, B., Dimitriadis, Y., and Martínez, A., "Quest, A Telematic Tool for Automatic Management of Student Questionnaires in Educational Research", 2nd European Conference on Technology, Information, Education Citizenship, Barcelona, Spain, June 2002. Anderson, G., Boud, D., and Sampson, J. "Learning contracts. A practical guide", Kogan Page, 1996. Joint Quality Initiative, http://www.jointquality.org, last visited: Mar. 2006. Martínez, A., Dimitriadis, Y., Rubia, B., Gómez, E., and de la Fuente, P., "Combining Qualitative Evaluation and Social Network Analysis for the Study of Classroom Social Interactions", Computers and Educations, vol. 41, no. 4, 2003, pp. 353-368. Martínez, A., Gómez, E., Dimitriadis, Y., Jorrín, I. M., Rubia, B., and Vega, G., "Multiple Case Studies to Enhance Project-Based Learning in a Computer Architecture Course", IEEE Transactions on Education, vol. 48, no. 3, Aug. 2005, pp. 482-489. Nud*IST. "Software for Qualitative Data Analysis", Scolari, 1997.
1-4244-0257-3/06/$20.00 © 2006 IEEE October 28 – 31, 2006, San Diego, CA 36th ASEE/IEEE Frontiers in Education Conference S2F-24
