So, guys, going forward now, let us discuss what are the challenges the designers came across when
they were designing and implementing automatic repeat request feature for TCP.
So remember, Arc is a complex feature and it is not that straightforward to implement.
TCP sending and receiving process may reside anywhere on the network right separated by tens of intermediate
routers in the network.
So you can see in this diagram the TCP sender is a and TCP receiver is B, and in between them there
could be any number of routers.
In fact, A and B may be communicating over an open internet so intermediate routers can themselves
impose limitations and problems such as packet loss or the routers could be slow.
So for example, suppose this router is a slow router and for example, suppose it can forward the traffic
at the rate of five megabytes per second.
So if this router only has a capability to forward the traffic at the rate of five megabytes per second,
it is meaningless if the TCP sender tries to inject the packet into the network at the rate of ten megabytes
per second.
Right.
It is useless.
The slow router will going to drop the packets, which it cannot process.
So you can see that slow network throws a challenge to tcp's IRC feature.
So you can see that TCP sender has to adjust as per the slow network.
Network itself impose problems on the rate of communication.
For example, this link between the two routers.
Itself is of bandwidth, say ten megabytes per second.
It simply means that TCP sender cannot inject the packet into the network at the rate higher than ten
megabytes per second.
A chain is as strong as its weakest link.
So in a nutshell, there can be any number of factors which cause disruption in the data flow between
TCP sander and TCP receiver.
Network is like an open ocean.
Anything can happen any time.
So several question arises to implement a strategy to deal with the packet loss or packet corruption
or other anomalies imposed by disturbing agents of the network.
These disturbing agents could be slow routers or links with limited bandwidth.
So now let us try to go through several questions which should be addressed by ideal implementation
of IRC strategy of TCP.
So the first question says that how receiver would detect whether the packet is malformed.
Now it is an easy one.
The TCP header has a checksum field and using that checksum field, the TCP receiver can always detect
whether the packet is malformed or corrupted.
Now how sender can determine whether the receiver has received the packet, right?
How long the sender should wait for an ack from the receiver.
Now we have not talked about ack until now.
Just assume that ACC is a kind of feedback which TCP receiver send back to the TCP sender telling the
TCP sender that the data has successfully arrived.
So the question says that for how long the TCP sender should wait.
For the acknowledgement packet from the receiver.
If the sender waits too long, it will cause underutilization of the network.
If the TCP sender waits for a very short period of time, then it will cause unnecessary retransmission
of the packet.
So we will going to discuss all this in detail in this course.
Then the fourth question simply says What if the acknowledgement itself is lost?
How receiver will manage when it receives a packet out of sequence.
What if the TCP receiver is slow than the sender or TCP receiver receives duplicate copies of the packet?
Now, you can see here that if the TCP receiver is itself is slower than the TCP sender, then of course
a stage will reach where TCP receiver will start discarding the extra packets here.
TCP receiver cannot process the packets at the rate which TCP sender is sending to it.
It means that there should be a mechanism where TCP receiver should tell the TCP sender to slow down.
So this is another requirement of arc.
What if the network itself is slower?
So in the previous slide we discussed that slow network can lead to a packet loss if TCP sender injects
the packet at a rate higher than the network can manage.
Contrary to this, what if the network recovers from its slow state and now can transmit the packets
at a full higher rate?
In such a situation, TCP sender and receiver should be intelligent enough to detect the condition that
the network has been recovered and they should be able to transmit or exchange the data at a higher
rate.
Now it will lead to network underutilization if the network has the capability to transmit the packet
at the rate of 100MB per second.
But TCP sender and receiver are exchanging the data at the rate of ten megabyte per second.
The ideal implementation of IRC says that TCP sender and receiver must squeeze the network capability
to its limits.
The next question says that with how much rate should the sender send the packets to the receiver?
So you can see that we shall try to find answers to all these questions in this course.
So the subsequent section of this course are all about finding answers to these questions.
TCP mechanism takes above stated points into consideration to implement its reliable data delivery functionality
over lossy network.
So you can see that overcoming all these challenges is not a joke.
TCP not implemented overnight.
It is an outcome of research spanning around 20 years with hundreds of research papers.