In traditional measurements for traffic characterization, the times that are to be measured are usually ranging from nanoseconds to about one second. A parameter that has been subject of many studies would for example be the mean inter-arrival time between packets. The granularity for measurement of such times in the micro- to nanosecond-range of course has to be very fine. In contrary, the time intervals we are talking about for flow measurements are rather macroscopic. Reasonable values for the flow-timeout are in the range of seconds to minutes.
Several people have worked on the timeout parameter. For their studies of wide-area traffic at the transport level, Caceres et al. [32] have used a 20 minute timeout, motivated by the FTP idle timeout value of 15 minutes. After comparing their results to a 5 minute timeout, they found only minimal differences. Estrin and Mitzel [10] also compared timeouts of 5 and 15 minutes and found only little differences for the flow durations at those two values. Acharya and Bhalla [1] used a fixed 15 minute flow timeout.
In the [6] and [15], Claffy, Braun and Polyzogos extensively examine Internet traffic on a large vBNS backbone node using different values for the flow timeout. One interesting result they found is that the majority of the flows between two hosts on the Internet don't even last longer than ten seconds. To examine the significance of the parameter, they used flow timeouts of 4, 32, 256 and 2048 seconds and compared the measurements.
Shorter timeouts tend to split longer flows into several short ones, so naturally smaller timeouts will yield a larger number of flows and a greater proportion of flows of smaller duration when analysing the traffic. However, even with a 2048 second timeout -- which is essentially considered to be infinitive compared to the 3600 second data duration during which the data was captured -- it was found in [6] that more than 27% of the flows consisted of a single packet of less than one hundred bytes. For timeout values of 64 seconds or less, 90% of the flows showed less than 50 packets, 5.5 kilobytes and 100 seconds of duration. From the data set it was known that the 80th percentile of the flows reflects about 40 packets or less and about 3.4 kilobytes of data or less. This led to the conclusion that a value of about 64 seconds should be reasonable to gather most of the flows.
The NeTraMet implementation, which we will introduce in chapter 3 uses a default value of 600 seconds for the timeout. This value can and should, depending on the traffic and host memory, be modified by the user.
It is evident that the choice of the flow timeout value always has to be dependent on the flow specification, the traffic that is to be measured and the memory that is available for the flow table. On a machine with lots of memory available that is used on a network segment where only a few flows per second would be measured, one would of course choose a much higher value for the flow timeout parameter than on a heavily loaded measurement point on a high-speed backbone network. In fact, for real measurement systems, it would eventually be interesting to do an automatic adjustment of this parameter so that always all of the available memory is used. However, no existing application has implemented such a mechanism yet.