In the fast retransmission logic in TCP, TCP retransmit the packet when the sender gets the 3 duplicated ACKs. However, what if the sender gets 6 duplicated ACKS?
The following procedure is what I think,
1) sender sends lots of packets with big window size
2) the first packet is dropped
3) Receiver sends ACKS that contains the seq # of the first packets. And other ACKS will have same ack numbers. (For example, the sender send 1,2,3,4,5,6,7 and packet 1 is dropped. Then, the receiver sends ACKs 1,1,1,1,1,1,1)
4) The sender gets 3 dup acks and retransmit the dropped packet However, the receiver still sends 6 dup acks because the receiver doesn't get retransmitted packet. Therefore, the receiver will send duplicated ACK until it gets the dropped packet
5) The sender gets 3 dup acks again, and retransmits the packet again.
Therefore, the sender will retransmit the packet repeatedly. I thinks this is weird. Is there any problem in the above procedure (scenario) ?
Or is there any TCP logic that can prevent the above problem?
Related
In the book on networking "Computer Networking: A Top Down Approach" by James Kurose following is stated:
"...sender in ... uses only a single timer, which can be thought of as a timer for the oldest transmitted but not yet acknowledged packet. If an ACK is received but there are still additional transmitted but not yet acknowledged packets, the timer is restarted."
If in a GB3 protocol with sequence numbers 0,1,2,3. Suppose packets 0,1,2 are sent by the sender and a timer is started according to oldest transmitted but not yet acknowledged packet no-0.
The receiver receives all packets in order.
The receiver (with a window size of 1) sends ack 0,1,2 one at a
time.
Suppose ack 0 is received at the sender.
Now according to above excerpt from the book, the timer has to be
restarted according to packet no-1, which is transmitted but not
yet acknowledged.
My Question: How does the sender restart the timer with respect to packet-1 when it has already been sent in the past keeping in view a single timer in GBN protocol?
The timer in Go-Back-N is not specific to a particular packet. It measures the time between two events, i.e, The oldest packet (base) transmitted and the ack received. If within the timeout no ack is received, all the packets from base are retransmitted. For each ack received the timer is restarted. Lets suppose the timer is 3 sec, and ack for packet-0 is received. It restarts the timer, i.e sets 3 sec timer and waits for an ack to receive (Either cumulative ack or individual ack). If the sender fails to receive the ack in the stipulated time, the timer is restarted and packets are retransmitted.
In case that a sender sent SYN at the first time, but the sender did not receive SYN/ACK in a timeout duration.
(Q1) When the sender retransmits SYN again, is the re-transmitted SYN same as the previous SYN?
(Q2) Are their sequence numbers same?
Yes it does, but you might observe a difference or two.
A retransmission is exactly what it sounds like; the original packet is retransmitted. This means that the source host, source port, destination host, destination port, initial sequence number, etc. are all the same.
However, if the system supports PAWS and sends the TCP timestamp option, you should expect that the timestamp will change. As a result, the TCP checksum will also change.
In the alternating bit protocol, how does the receiver know the difference between a delayed packet and a correct one. For example if the sender sends a packet with seq#0, it gets severely delayed on the way there, so much so that the sender and receiver have completed 2 packets in between and the receiver is expecting the next packet with seq#0, and instead receives the delayed one. Should the receiver have a temporary storage of the last few packets to compare if it's just delayed or are there other ways to check?
As I understand TCP starts a retransmission timer for each data segement it sends and retransmit the packet (assume no dup ack received from receiver) whenever the timer expires and restarts a new timer with longer duration until failures numbers have reached some limits.
Just wondering if it does the same thing for FIN packet loss in transit ? (such as tries of retransmission, timer length increase etc.)
For example, in below TCP close chart,
If 1st or 3rd FIN is lost, does TCP use same logic to retrasmit it like a normal data segment before it fails ?
if after 1st FIN is sent we never heard from receiver for 1st ACK, does sender have to shutdown the TCP connection on its own or have to keep it alive ?
if sender never gets 2nd FIN from receiver, sender should be still in FIN_WAIT2 state, what might be the timeout (I guess not 2MSL ? ) before it directly moves to closed state ? Or does it do it at all ?
As I understand TCP starts a retransmission timer for each data segement
Each segment except an ACK-only segment.
it sends and retransmit the packet (assume no dup ack received from receiver)
Duplicate ACKs don't have anything to do with it.
Just wondering if it does the same thing for FIN packet loss in transit?
Yes.
If 1st or 3rd FIN is lost, does TCP use same logic to retrasmit it like a normal data segment before it fails?
There is no 3rd FIN in the state diagram, but they are subject to retransmission.
if after 1st FIN is sent we never heard from receiver for 1st ACK, does sender have to shutdown the TCP connection on its own or have to keep it alive?
It stays in FIN_WAIT_1 until acknowledged or retries expire.
if sender never gets 2nd FIN from receiver, sender should be still in FIN_WAIT2 state, what might be the timeout (I guess not 2MSL ? ) before it directly moves to closed state ? Or does it do it at all ?
Not at all. The connection stays half open, just as though the sender had done an output shutdown.
I am facing a problem related to the TCP retransmissions.
My Sender starts sending some data to receiver (which is not in the network after opening the connection), after sending 3 packets, it retransmits first packet 3 times (as per the retransmission timeouts)and start sending next packets.
Then it retransmits first packet again. I am not able to understand this behavior and want to know if there is some way I can disable this and force TCP to retransmit first packet and then close the connection if no ack is received.
Thanks.
No there isn't. It's a streaming protocol, not a datagram protocol.