It is quite time-consuming to emulate the entire day's worth of delays, multiple times over, to test and tune the different parameters in each scheme. One work-around could be to choose a smaller portion of the delay traces (e.g., 2 hours). However, a quick analysis of the delay traces we collected shows that there is not much variations in the delays along the probed paths on a 2-hour timescale. Since our goal is to understand how effective each scheme is over a wide range of operating conditions, it is important to test how well the schemes handle frequent changes changes in the performance of the underlying network paths. With this in mind, our approach is to compress the 24-hour delay traces by a factor of 10, to 2-hour delay traces and use these as the real inputs to the WaspNet delay module. In these 2-hour traces, performance changes in the underlying paths occur roughly 10 times more often when compared to the full 24-hour trace. The characteristics of the 2-hour delay traces collected from the nodes in Chicago are shown in Table 1, column 2. We use these delay traces in our emulation.
We also wanted to ensure that the delays observed from the Chicago source nodes were not significantly different from typical delays experienced by a well-connected, multihomed network located in a major U.S. metropolitan area. Hence, we collected similar traces from 3 source nodes located in two other cities, namely New York and Los Angeles. These traces were collected on March 20th, 2004. The statistics for these latter traces are shown in columns 2 and 3 of Table 1. These statistics show that the Chicago-based traces we use in our experiments have roughly the same characteristics as those collected at the other metros.
Among other configuration issues, for both FrequencyCounts and
SlidingWindow we choose parameters in such a way that either
mechanism roughly tracks the top 40 destinations. We vary the other
parameters such as the sampling interval 
and the EWMA constant
.
