VanillaTCP without DRS

The same thing holds for the variation of the stdev of the thruput as it does for the VanillaTCP-DRS case.

As we can see, the growth of the AveCwnd is not linear as expected. In fact it remains quite low initially, and increases quite violently. Note that we do actually achieve a much larger window size than with DRS.

Plotting the thruput against the average cwnd value shows that we get two main regions:

• A linear region where the cwnd limits the thruput.
• A plateau where the extra growth of the cwnd value doesn't make a difference to the thruput because we've reached line rate.

There is also a strange form to the stdev of the InstBW's. We can see that the stdev closely resembles the average rates for the linear region. This makes sense for the same reason as it does with the DRS case. We then reach the top of the linear region and the stdev decreases.

WHY? why the hump?

The above graph shows explicitly that we limit the number of pkts going out by the size of the cwnd - upto the plateau which represents line rate.

The two graphs above show that we get a steady increase in the number of slowstarts; this is caused by the OtherReductions which force cwnd to drop. The latter graph shows that we do so many congavoids; then past 1e7, we do none due to the fact that we do not get any CongestinSignals - THIS IS NOT TRUE - why do we not get any congavoids?

The above graph shows the variation of the types of acks for the different pkt drop rates. We see that number of dupacks decrease as we lower the loss rate. SHAPE?

We see that the number DSACKDups increase steadily as we decrease the loss rate. DOES THIS MEAN REORDERING IS INCREASING?

The above graph shows the total number of packets that are send out and recieved for each loss rate. As we appoach the line rate, we can no longer put more packets onto the network, and hence the number begins to plateau off.

Looking at the ~10ms rates, we see that the stdev of the pkts in and out follow the same reasoning as it does in the VanillaTCP-DRS case.

the following graph shows that TCP is doing well in sending back only what is missing.

The following graph shows the faction of packets which were retransmitted as a result of recieving dupacks (we don't get any timeouts). The one thing to note is that we get a lot more dupacks than expected; assuming that we loose only what we specify (and this is affirmed by the packets that are retransmitted), then we should get three dupacks for each packet lost (induced lost).

However, the graph below shows that we actually get a lot more; FractionDupAcksIn is the number of dupacks over the total number of packetsIn (assume all acks). FractionPktsRetrans is PktsRetrans / Total pkts out.

Considering there is a discrepancy in the denomintor; we shall assume that we are delyed in acks (ie 2 data packets for every ack). This would account for a factor of 2 difference in the numbers. This should mean that we should get 6 times more FractionDupAcksIn than FractoinPktsRetrans. Judging from the graph above, this is still incorrect.

Plotting the fracions against each other shows a more meaningful relationship between the two variables. It's slightly curved, but assuming linearity; get get about (0.3-0.001)/(0.01-2.5e-7)~29.9 fraction dupacks/fraction pkts retrans.

WHAT DOES THIS MEAN??? -> get approximaetly 5 times more dupacs as expected? Can this be used as a indication of reordering on the line? Why is there reordering???

The following graph shows that we cannot use the assumption that we get acks for every other datapkt.

From the graph below, we also see a gradual increase in the rtt of the flow; this could be due to the fact that past a certain rate, the routers can no longer service the packets fast enough to keep the queue lengths to a minimum; hence the queues build up and the rtt increases.

Mon, 4 August, 2003 14:24