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.
Related
Whenever I download something it starts slow but gets faster overtime then stays the same whereas speed in UDP increases or decreases randomly.
So my question is, what causes TCP to get faster and why UDP is more unstable compared to TCP?
So my question is what causes TCP to get faster
Most likely that is due to TCP's slow start feature, which is designed to avoid overloading the network with too much traffic by starting out at a conservative pace, and only increasing the transfer rate once the algorithm has recognized that the network is handling the initial rate without too many dropped packets. The rate will increase until packets start being dropped, at which point the TCP layer will back off a bit, until finally it (hopefully) arrives at the fastest transfer rate that network conditions can reliably support.
why UDP is too unstable when compared to TCP?
Unlike TCP, UDP doesn't make any attempt at congestion control; that sort of thing is left entirely up to the application programmer. All UDP does is send individual UDP packets (when the calling program asks it to by calling send() or sendto()), which may or may not arrive at their destination; if they do not arrive (for whatever reason) no further action is taken by the transport layer. So any particular behavior you see with UDP packets is more an indication of how your UDP-using application was programmed, than an indication of how the UDP transport layer behaves.
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
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.
While talking about UDP I saw/heard congestion come up a few times. What does that mean?
congestion is when you are trying to send too much data over a limited bandwidth, it cannot send the data faster than the incoming amount so additional packets are dropped.
When congestion occurs, you can see these effects:
Delay due to the queue at one end of the connection being too big, so it takes time for your packet to be transmitted.
Packet loss when new packets are simply dropped, forcing connection resets (and often causing more congestion).
Lower quality of service, protocols like TCP will do a cutback on the transmission rate, so your throughput will be lowered.
Blocking, certain networks have protocol priorities, so your UDP packets may be dropped in favor of allowing TCP traffic through.
Its like a traffic jam, imagine right after a sports game where a parking lot full of cars is trying to empty out into a small side street.
It means that network-connected devices are attempting to send more data across the network than it can handle, e.g. 20 Mbps of data across a 10 Mbps link.
In context of UDP, it's your main source of lost datagrams under ordinary circumstances.
Most LANs use some sort of a collission detection/avoidance system. A congestion typically means that the amount of data which is being transmiited on the medium is causing enough collissions to deteriorate the quality of service defined for that medium.
You may want to read up CSMA/CD at wikipedia.
As UDP packets can often be broadcasted, congestion can occur more often.
Kind regards,
For instance, Ethernet is a broadband protocol. Once a message is sent, every node receives it but ignores if the packet are not sent to them. What happens when two nodes send a packet at the same time? It will cause a collision and data loss.
So, both of the nodes will have to resend the message. To avoid more collisions, nodes are designed to wait a random number of milliseconds. Otherwise they keep going on sending messages simultaneously and packages will collide forever.
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.