[TCP]: Add F-RTO support.
Motivation for this modification is that especially on some wireless network technologies there are delay spikes that trigger RTO even though no packets are lost. F-RTO sender continues by sending new data after RTO retransmission in order to avoid unnecessary retransmissions in that case. If the sender sees any duplicate acks after the RTO retransmission, it reverts to traditional slow start retransmissions. If new acks arrive after forward transmissions, they very likely indicate that the RTO was indeed spurious and the sender can continue sending new data (because only one segment was retransmitted).
Showing
Please register or sign in to comment