Testing collaborative traffic over wireless protocols

As technology advances, new opportunities present themselves for computer supported learning in educational environments. One of the enabling technologies for these opportunities is wireless networking. Without being tethered to wires, students can use laptops and other wireless devices both in and out of classrooms for group work and self-paced learning. This will help prepare them for a collaboration-driven global workplace, and it promotes new opportunities for distance education. However, wireless communications currently suffer from several inhibiting problems stemming from the underlying network protocol used by the software. The Transmission Control Protocol (TCP) is the most utilized standard in networking and is well known for its reliability, but it was built to work with wired networks and its assumptions for the cause of packet loss do not fit with the reality of wireless environments: loss is caused by inherent problems in the network layer and not data collisions. Because of this, the User Datagram Protocol (UDP) is often used in wireless environments since it can achieve higher levels of through-put by not slowing down traffic to prevent data collisions, unlike TCP, and it supports multicast transmissions. However, UDP provides no reliability; if any packet is lost, it is gone forever. In educational environments, packet loss is not acceptable because every piece of information sent by a teacher or student is important, and throughput is necessary because slow software inhibits productivity and learning. To help resolve this problem, we have tested the experimental Pragmatic General Multicast protocol (PGM), which supports both reliability through lost packet retrieval and high throughput by not scaling traffic and by using multicast transmissions. Our tests in a real-time collaborative classroom environment of over thirty wireless laptops via the Microsoft ConferenceXP platform have promising results: we encountered no problems in throughput or packet loss. However, we discovered problems with message latency, so we conducted further tests and present our results in this paper.