Is there a way to retrieve packet loss or in this case retransmissions that have occured on a QTcpSocket? If there is a way, is there also a way to check the total amount of packets sent vs retransmissions?
Related
I have multiple sensors transmitting periodic readings to a server over internet. The frequency of transmission is 100ms. The message size will vary from 1KB to 12KB. I wants to keep the packet loss less than 5%. I read that the safer size for UDP datagram is 512B when transmitted over internet. Personally i did experience packet loss more than 10% when datagram of size 12KB were used. One solution would be to split the message and send it number of smaller message. But it is a huge overhead. Can i use TCP in this case instead of UDP? Is there any problems to take care while using TCP for periodic messages?
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'm not an expert in networks. So I would like to know what is the maximum reasonable time bewteen receiving two rtp packets upon which if passed the stream would be considered timedout.
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.