Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Networking TCP/IP

Assume two hosts, A and B, communicate via a TCP connection. Reliable data transfer is guaranteed by TCP's retransmit mechanism: if host A sends a segment and the segment is lost or corrupted, then it will not be acknowledged by host B. After A's retransmission timer times out, and still no ACK has been received, A will retransmit the segment.

A possible problem with the above scenario is this. Assume that a fast stream of segments is being sent. If a segment is lost, then the receiving host B can notice this quickly from the
sequence nunbers. But the segment will be retransmitted only later, when A's retransmission timer times out, since before it A does not know about the need for retransmission. By that time, however, the segment may become useless in a fast real-time application.

The above problem clearly stems from the fact that A does not know that retransmission is needed, before the timer times out. Even though B knows it earlier from the sequence numbers, it does not have a standard way in the original TCP to notify A about it. If B could somehow notify A to initiate an early retransmission, then the unnecessary delay could
be avoided.

Your task is to propose a simple solution for this problem. Specifically, propose a simple modification of the TCP protocol, which makes it possible that the receiver can notify the sender that a segment needs to be retransmitted. The goal is that the sender can
learn about the needed retransmission, without having to wait for a timeout. Let us call this protocol "TCP with Fast Retransmission" and let us abbreviate it as TCP/FT. Your proposed solution for TCP/FT should satisfy the following requirements:

Simplicity. It should be a simple modification of TCP. Do not attempt to totally redesign TCP.

Failsafe design. To avoid potential interference with existing implementations, you are not allowed to put any new type of information in the TCP header, including the Options field. Thus, for example, it is not acceptable to say: "let's use one of the unused header bits to include a special flag that instructs the sender for an early retransmit".

Backward compatibility. Your proposed protocol should not cause any problem if the communication takes place between a host that attempts to use TCP/FT, while the other runs standard TCP and does not know anything about TCP/FT.

Present your proposed modification of TCP first by explaining its operation verbally. Then also present it in some more formal way, prefereably by a flowchart or pseudocode. (If you use pseudocode, then add enough comments to make it human readable!)
Sign In or Register to comment.