We have measured both UDP and TCP performance in different scenarios. For all UDP measurements, we have used two tools, one for configurable packet transmission (including statistics reporting) and a receiving tool providing detailed logs for the incoming packets. We have transmitted packets of different sizes and at different intervals. In each measurement, we have used one active sender station transmitting packets to the other, using UDP/IPv4 unicast; our tests covered both directions, fixed (Ethernet-based) laptop to mobile and vice versa.
Our UDP-based tools have used RTP as a transport protocol. In particular, we have used RTP sequence numbers to assess throughput and packet loss, and we have used RTP timestamps plus additional (finer-grained) timing information in the actual payload to monitor relative packet delays.
Our sending tool rtpsend can be parameterized with an IPv4 destination address and a port number, with an interval between consecutive packets and with an RTP packet size, i.e. the size of the whole UDP packet including the twelve bytes for the RTP header.
The receiving tool rtpspy logs each received packets and its RTP header information, especially the sequence number and the RTP timestamp plus, optionally, additional timing information contained in the payload. Based on the complete list of all received packets within a time frame, rtpspy can generate statistics for a session, e.g., on the average throughput, packet loss totals and histograms of consecutive packet loss. Using the RTP timestamp, rtpspy can calculate relative transmission delays by considering all received packets and comparing their RTP and payload timestamps (sending time) with the time of receiving the packet. We have extracted further statistics from the log files by means of extensive scripting.
For most measurements, we have used packet sizes of 1250 bytes and have used sending intervals of 4ms, 2ms, and 1ms, i.e., 250, 500, and 1000 packets per second.
For TCP measurements, we have developed a tool called tcpx (TCP exchange). tcpx can be started in either server mode or client mode. In server mode, tcpx will multicast periodic UDP trigger messages and listen for a new connection on a specified port. In client mode, tcpx will wait until it receives a trigger message from the server, e.g., when the client system enters the local network in which the server resides. The trigger mechanism is used to automate the reachability detection and the connection setup when the mobile station enters the Drive-thru WLAN cloud. Upon reception of a trigger message, the tcpx client establishes a connection and transmits a TCP message exchange specification to the server, thus defining the communication characteristics of the TCP session. Communication is modeled as a series of request-response interactions, where the client sends a certain number of bytes and the server responds with a certain number of bytes. The request and response message size can be parameterized when starting the client and is sent to the server in the initial configuration message. The client and the server are synchronized, i.e., each party waits until the specified number of bytes has been received before it starts sending.
After the initial configuration message, the client and the server start to exchange bytes following the specified pattern for a user-defined amount of time or until the TCP connection is lost. Both the client and the server periodically report the number of bytes sent and received. The interval between these reports is configurable, and for our tests, we have used 300 ms.
In order to compare TCP behavior to the UDP measurements and in order to measure the throughput in one direction, we have configured the tcpx instances to perform a one way communication, i.e., either the client or the server sends.