[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] when dupACK keeps arriving, TCP Reno doesn't send packetseven though there are no outstanding packets. Why?
I'm not sure whether I understand your question correctly.How
much is the buffer size on the link? And how big is the packet size?
If you used default 1000 bytes, the pipe can only allow 1 packet
pass through. So I assume your buffer size is 100 packets.
Even with such a setup, TCP
should eventually adapt its window to the actual network pipe
size by adjusting parameters like ssh_threshold, estimated RTT,
etc. (I'm assuming that you omitted the intermediate
cwnd values in your description).
And I don't understand how you can get 44 duplicate ACKs. Does
that mean you have lost 44 packets? Or you have 44 packets
sitting behind a extremely large packet sent by the CBR agent?
(BTW, what's the packet size of the CBR?)
In one words, I guess you are simulating TCP under a very strange
setup, namely, a very narrow pipe with a big
buffer, and TCP is trasmitting together with an extremely
bursty UDP traffic. In such case, it makes sense that TCP
congestion control behaves strangely. However, it still
maintains the ability to transmit at the desired rate
(around 30 packet/RTT, which can be computed by (0.5-0.35)/0.5 * (100 +
1)), although the cwnd varys quite drastically
due to the extremely high variable queueing behavior.
On Fri, 28 Jul 2000, Yingfei Dong wrote:
>
> 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
>
>
>
>
Guo, Liang
[email protected] Dept. of Comp. Sci., Boston Univ.,
(617)353-8924 (O) 111 Cummington St., MCS-217,
(617)375-9206 (H) Boston, MA 02215