what is the diffrence between TCP TAHOE and TCP RENO.
what I want to know is about the behivor to 3-dup-ack and timeout?
what happend to cwind what happend to SST?
thanks!
TCP Tahoe and Reno are two forms of handling TCP congestion controls specifically when it comes to receiving 3 duplicate acks.
Tahoe: handles 3 duplicate acks similar (exactly?) to receiving a timeout. It first performs a fast retransmit. Then, it halves the ssthresh value to original congestion window size, and sets the new window size to 1 and staying in slow start.
Reno: The successor to Tahoe, goes into fast recovery mode upon receiving three duplicate acks thereby halving the ssthresh value. For each successive duplicate acks (fourth, fifth, sixth), cwind increases by 1. Once the receiver finally receives the missing packet, TCP will move to congestion avoidance or slowstate upon a timeout.
Source: TCP congestion control - TCP Tahoe and Reno
Related
I read a lot blogs about tcp protocol. They all mention the congestion avoidance that once the timeout occured, tcp will set the ssthresh half as before. But none of them refer to how to increase the ssthresh. I'm curious about it when/how to increase ssthresh.
I have an assumption that every tcp connection has its own ssthresh, and there is a default value of the ssthresh, which every tcp connection'ssthresh increses from. I don't know if I'm right, or if there is any other mechanism?
From what I studied, congestion avoidance phase sets CWND = CWND + MSS * (MSS/CWND) every time a new acknowledgment is received. This is assuming we don't encounter duplicate ACKS or timeouts. But what happens if there are delayed acknowledgements ?
Here's what I think from research on delayed acks (no idea if this is correct):
Basically Delayed ACK is the destination retaining the ACK segment for a period of time expecting one of two things.
Either there will be more ACKS will be required to be sent before the timer is up because of new packets recieved by the receiver. OR the receiver will need to send some data back to the sender in which case it can piggy back the message on that packet.
How does this affect the congestion avoidance phase ?
This would be bad for congestion avoidance phase of TCP which depends on new Acks to increase CWND. This would cause delays in CWND window size change thus causing delay in the sending of packets. This means by the time that TCP could be sending packets to the receiver, it is actually not because acknowledgments are being delayed.
This affects the congestion avoidance phase the same way it affects the other phase (SS) : it will slow down the traffic. However, keep in mind there are two different network uses, the interactive one (such as telnet), and the bulk one. Delayed Acks are likely to be used with interactive protocols sending very small amounts of data, but this can bring new problems if Nagle's algorithm is used by the other side. When unsure, just disable delayed Acks.
That is a really good question. Since they keep the bottleneck buffer full, delayed Ack is not a big problem for traditional congestion control algorithms such as Reno and CUBIC.
For TCP Vegas which tries to keep the queue small, it is still not a problem because if it faces delayed Ack, it will reduce cwnd very slowly (one unit every RTT). Therefore a Vegas connection will not suffer from under-utilization unless delayed ack lasts for a very long time.
I have a question about the increasing rate of TCP sender's congestion window during the slow start phase.
Traditionally, the size of cwnd exponentially increases for every RTT. For instance, if the initial cwnd value is 1, it increases 2->4->8->16->.... .
In my case, since the sender uses linux kernel 3.5, the initial cwnd is 10.
I expected the cwnd increases as 10->20->40->... without delayed ACK (I turned it off at the receiver). However, when the receiver downloads a large size (over 1MB) of object from the sender over HTTP, cwnd increases as 10->12->19->29->.... I cannot understand this sequence.
I set RTT to 100ms and the link bandwidth is high enough. There is no loss during a session. I estimated the sender's cwnd by counting the number of packet the receiver received within one RTT.
Does anyone have idea for this behavior?
Thanks.
The dafault congestion control algorithm in kernel 3.5 is not TCP Reno, but CUBIC.
CUBIC has different behavior. It stems from BIC, and I know that CUBIC share slow start phase of BIC. Just see codes of BIC and CUBIC at /usr/src/yourkernelname/net/ipv4/tcp_cubic.c.
Moreover, delayed ack MAY result in such sequences. You know, 'traditional' TCP congestion control behavior is TCP reno without DACK nor SACK.
Know that even current TCP reno in Linux is not reno but new reno (reno with SACK).
Check the options of Delayed ack and Seletive ack using sysctl command.
I am testing a GNU Radio program which can tunnel TCP traffic over a wireless link. We are having some strange results in testing, and in looking for a culprit I was curious about inconsistent latency.
How can inconsistent latency affect TCP applications? By inconsistent I mean widely different RTT for ACKs on a connection. For awhile ACks seem to be coming at a normal rate, then they disappear and we have retransmissions followed by the 'delayed' ACK.
For instance, say the first several ACK's received have a similar RTT. What would happen when the next ACK isn't receieved in twice the RTT of the previous ACKs? Whatever the issue is I see lots of retransmissions after a long wait for an ACK.
Now, more specifically, how can RTTs for ACKs which bounce between fast and slow affect a TCP connection?
Having said that, is there any way to tune the IP stack to handle this environment better?
TCP maintains a smoothed RTT (SRTT) to tell it how fast the intervening network is, i.e. how fast it can transmit. If the SRTT goes up TCP will slow down. If SRTT goes down TCP will speed up. If the actual RTT goes up and down violently, TCP may not react quickly enough, due to the smoothing, and transmit too fast, which would cause packet loss, which in turn causes retransmission, which wastes the bandwidth used by the lost packets. RTT smoothing is done via exponential decay with a gain of I think 0.2, so the old SRTT value has four times the weight of the current RTT when computing the new SRTT value.
I've been researching TCP congestion control recently, however one question plagues me...
If I understand everything correctly, TCP will not send NEW data unless allowed by the cwnd (congestion window) and rwnd (the receiving side's window). In other words:
if(flightSize < MIN(cwnd, rwnd))
{
// Send some new data (if possible)
// Taking into account other details that we don't need
// to get into such as Nagle's algorithm, etc.
}
Where flightSize is the amount of data that has been sent but not yet acknowledged.
Let us assume that TCP is going along, sending data, and increasing cwnd as appropriate. Let's say cwnd = [10 full packets], and the flightSize == cwnd. Then packet loss occurs in the network, and the sender's retransmission timer goes off. How/When does New Reno retransmit the unacknowledged data?
Here's my current understanding/misunderstanding:
When the timer goes off, the cwnd will be reset to [1 full packet], the oldest sent but unacknowledged packet will be resent, the rto will be doubled, and the retransmission timer will be reset. So if we say the rto was 1 second when the timer went off, it will get updated to 2 seconds, and the retransmission timer will get started again with a wait time of 2 seconds.
Here is why I'm confused:
In the above situation, TCP will resend only a single packet. Even if that packet gets ACKed right away, TCP cannot send any NEW data because cwnd is still less than the flightSize. So what does it do? Sit around and wait until the 2 second retransmission timer goes off again before it resends another packet? Does it force a resend of the old data since it can't send new data? Does it reset the flightSize, and reconsider all previously sent data to be unsent?
I've read all the RFC's I could find, and all kinds of guides and explanations of TCP. I must have missed something somewhere...
Clarification:
I was considering multiple losses, where TCP is not using SACK.
If duplicate acks are received, TCP will resend the oldest ack on the 3rd duplicate ack (fast retrasmit) and will send new data on and after the 4th duplicate ack (fast recovery). My question concerns what happens if the TCP sender gets less than 3 dup acks?
I found the answer in the book "TCP/IP Illustrated, Volume 2", section 25.11, pages 842-844:
[On a retransmission timeout] the next
send sequence number (snd_nxt) is set
to the oldest unacknowledged sequence
number (snd_una). ... By moving
snd_nxt back, [TCP can begin to
retransmit all unacknowledged data].
In other words, the flightSize will get reset, so data can continue to be sent (in slow start mode). It's just that some of this data may be data that has already been sent before. A cumulative ack might come along that prevents all data from being resent though.
Request for clarification: are you considering a single packet loss? Or multiple losses within a window?
In a single loss case, there will be duplicate acknowledgements received because of packets received after the lost one. I believe New Reno will transmit subsequent packets ("NEW data") in response to the duplicate acks. This then resets the timeout timer.