[ns] when dupACK keeps arriving, TCP Reno doesn't send packets even thoughthere are no outstanding packets. Why?

[Yingfei Dong <dong@cs.umn.edu>]

hi, folks,

I found a situation in TCP reno congestion control which is hard to
understand.

I have a TCP flow and a CBR flow on a same 0.5Mb-2ms link. The CBR is
0.35Mb. the TCP flow is a ftp. TCP is set to ack every packet recv.

When the TCP flow is in steady state, cwnd changes regular in this way

    k RTT	1 RTT        m RTT 		k RTT      1 RTT
46---------> 23 ----> 11 ----------------> 46 ---------> 23 ---> 11

------>... (loop)


1) When cwnd reach 46.xxx, 3 dupACK happen. There 46 outstanding packets.
   cwnd is set to 23, and ssthesh is set from 11 to 23. ssthesh=11
   from last steady state period.

   Then, more dupACKs (upto dupack 44) come. The number of outstanding
   packets keeps reducing. Before the number of ourstanding packets is
   decreased to less than 23, no packets are sent. 
   When the number of out standing packets is less than 23, the TCP sender
   starts to send a packet whenever a dup ACK comes.

   Until a real ACK comes after dupack 44, cwnd is increased from 23.000
   to 23.043. Then 3 dupacks happen again. cwnd and ssthresh are set to
   11.

2) There 21 dupacks after cwnd and ssthesh cuting from 23 to 11.


   Same as the above. dupACK keep arriving because of 23 outstanding
   packets. The number of outstanding packets keep descreasing. 

   But, the TCP sender doesn't send any packets even though the number
   of outstanding packets is smaller than 11, even when the number
   of outstanding packets is 0.

   until a real ACK comes, cwnd is set to 11.091 and the TCP sender send a
   "burst" of 11 packets.


My questions are: 

1) why the TCP sender doesn't send any packets even though
   the number of outstanding packets is 0 in the latter case?
   It does send packets in the first case when the number of outstanding
   packets are less than cwnd.

   The only thing I can think of is, in the first case, ssthesh is change
   from 11 to 23, but in the later case the ssthesh is changed from 23 to
   11. But it should be irrelevant.

2) cwnd doesn't increase when receiving a dupACK. It sounds reasonable.
   But it is not standard stuff, right? For estimate RTO, Karn's
   Algorithm doesn't count ACKs for retransmitted packets. Is there a 
   similar algorithm for dupACK? Or, it is just an optimization of NS
   implementation?


Please drop me few lines if you have some ideas. Thanks a lot.


Yingfei