I'm preparing an exam and I stumbled upon kind of interesting question. Basically what happens when for whatever reason the receiver receives the packets in reverse order?
For example I have a window of size 2 and I send packet 2 and 3 but 3 arrives faster than 2.
I'm not quite sure about the answer so I'll ask here.
Does the receiver sends a duplicate ack upon arrival of 3 and then ack2 upon arrival of 2?
And then, what happens to the transmission window?
Related
Can someone explain it to me as to why in selective repeat it's not possible for an acknowledgment to come for a packet that falls outside the current window? Because it may be possible that there is some delayed acknowledgment. It's possible in all sliding window protocols then why is statement 2 only true?
Moreover, in the solution, they mentioned that statement 2 is true because GBN has cumulative ack because of which if we receive ack 2 then the sender will assume that both packets 1 and 2 have been received successfully and so it slides the window to remove 1 and 2 from it but later we might get ack 1 which I feel is not possible because here we are talking about cumulative ack not independent.
So how is this reason valid?
Let's start from the back. Cummulative acknowledgments do not imply that there are delayed acknowledgements. GoBackN can in theory not acknowledge every single packet, but this is an optimization of practical protocols. So, I would assume, that GoBackN acknowledges every single packet.
Assuming that GoBackN acknowledges every single packet, the situation you are describing can happen. The receiver has received all packets in order, and send ACKs to every single packet in order. The channel however does not guaranty (reliable) in order delivery, i.e., the ACKs can arrive in arbitrary order. If two ACKs were reordered, exactly what they describe will happen.
In selective repeat each packet acknowledges only the packet received. And this only happens if the packet was sent. And the packet can only be sent as a part of sender window. Also, since ACKs are not cummulative, if the ACK for the second packet in the window is received first, the window will not move (since first packet is not acknowledged).
edit Actually, what could happen in selective repeat is following. Sender sends a packet, and receives no ACK. Then the timer fires, and the packet is retransmitted. And after the timer has fired, the first ACK has arrived. The window moves. Then, some time after the second ACK arrives, and it is outside the window. This can happen if the timer is set incorrectly, or if the ACK spent too much time somewhere in transit (which should be covered by the channel model). So, I guess you are correct, saying that it is possible.
Also, delayed ACKs usually refer to a TCP receiver, that does not acknowledge every received packet, but instead sends a single ACK for several of them. With cummulative acknowledgements this works trivially, since ACK for every single packet is not required. I don't see any way to implement delay acknowledgements for selective repeat, expect send 2 acks in the same packet, but then these ACKs will be for packets inside a window.
While refreshing some old theory, and solving couple of problems, one instance had me confused: "7 packages (0 to 6) with window size 3 are sent. Packet no. 2 ACK is lost the first time it is sent, and packet number 4 gets lost the first time it is sent"
I am aware that the window size will now encompass packets [2,3,4] since ACK2 has not been received a timeout would occur, and that same window will be re-sent. But Packet 4 is lost.
I have tried to depict, what I think happens. Forgive my sketching skills:
For completeness. Lost acknowledge will not cause retransmission, because acknowledgement for next packet will implicitly ack the missing one.
I know this probably doesn't happen in real life at all, but I am curious. I was studying for an exam and came across a theoretical question while doing some sliding window problems as I wrote one down incorrectly; what happens if the RWS (receiving window size) and SWS (sending window size) are somehow mismatched? As an example, let's say I'm sending 10 packets of information, with a timeout of 1 RTT, but the SWS is 4 but the RWS is 3. For this purpose, let's say that the RX side is not able to send an ACK for packet 1 before packet 4 arrives so the window is not "slid" in time.
My idea was that the extra 4th packet is just discarded and never ACK'ed, so it would time out on the TX end and resend packet 4 after 1 RTT, and continue this process for 5,6,7,8 with 8 being the one discarded and having the same process done. Would this be a correct assumption? Or is there something to this that I'm maybe not understanding?
Thanks in advance.
Context
We have got un unsteady transmission channel. Some packets may be lost.
Sending a single network packet in any direction (from A to B or from B to A) takes 3 seconds.
We allow a signal delay of 5 seconds, no more. So we have a 5-second buffer. We can use those 5 seconds however we want.
Currently we use only 80% of the transmission channel, so we have 1/4 more room to utilize.
The quality of the video cannot be worsened.
We need to use UDP.
Problem
We need to make the quality better. How to handle lost packets? We need to use UDP and handle those errors ourselves. How to do it then? How to make sure that not so many packets will be lost as currently (we can't guarantee 100%, so we only want it better), without retransmitting them? We can do everything, this is theory.
There are different logic's to handle these things.It depends on what application you are using. Are you doing real time video streaming? stringent requirements?
As you said you have a buffer, you can actually maintain a buffer for the packets and then send an acknowledgement for the lost packets (if you feel you can wait).
As this is video application, send acknowledgements only to the key frames. make sure that you have a key or I frame and then do interpolation at the rx side.
Look into something called forward error correction, fountain codes, luby codes. Here, you will encode the packets 1 and 2 and produce packet 3. If packet1 is lost, use packet3 and packet2 to get the packet1 back at the rx side. Basically you send redundant packets. Its little harsh on network but you get most of the data.
Can somebody just simplely describe the retransmission mechanism in TCP?
I want to know how it deal in this situation?
A send a packet to B:
A send a packet.
B receive and send ack,but this ack is lose.
A timeout and resend.
In this situation B will receive 2 same packets, how can B do to avoid dealing the same packet again?
Thanks.
Each packet has a sequence number associated with it. As data is sent, the sequence number is incremented by the amount of original data in the packet. You can think of the sequence number as the offset of the first byte in the packet from the beginning of the data stream although it may not, likely will not, start at zero. When A sends the retry, it will use the same sequence number it used the first time. B tracks the sequence numbers as it receives data and can know that it has seen the retry's sequence number before. If it has already made that data available to the (upper layer) client, then it knows that it should not do so again.