CB Background with DRS TCP

By shooting cbr udp traffic along the link, we hope to see the effects of these new tcp stacks when queue build up in the network path (bottleneck). The main changes would be that network queues get filled when the bg load increases. This would make the latency experienced by the tcp to be higher. Also, as the average queue lenghts are increased due to the background load, more drops should be experienced by the tcp streams.

We see from teh above graphs that all stacks achived identical performance due to the low latencies involved. From this, there doesn't appear to be any percieved benefit in using the other stacks on this network.

Looking at the CoV (stdev bw/ave bw) shows that it is almost identical also. However, there is a region whereby HSTCP and Scalable achieve worse performance (high CoV) from 600 to 850mbit/sec bg. It then get's better than VanillaTCP. This means that given the ave bw's are similar, that the stdev of the hstcp and scalable streams are higher for the first region. And then better. This sugests that the newer stacks are more benefical in highly loaded networks; but perhaps worse in medium-highly loaded networks.

Looking at the average cwnd shows that we are DRS limited for most of the experiement: only after about 600mbits/sec bg do we get the effects of the bg load affect the tcp. This suggests that DRS actually makes TCP fairer as it prevents the growth of the cwnd.

We see that the newer stacks actually manged to maintain, on average, a smaller cwnd value; this would explain the high stdev experience on the tests.

We can see that the smaller cwnd is caused by the fact that we actually get a lot more congestion signals from teh network (actually tcp trying to stablise).

We see all three stacks following the same pattern for below 600mb/sec - this is due to the DRS algorithm. However, once we get past 600, we see that the newer stacks actually have to retransmit a lot more packets - upto about 20x as much! This

{blank}

Thu, 14 August, 2003 17:46