 The next question that we want to address is how many such packets should we send at a time? So, let's take a pause here and Consider this question. Okay. There is a sender at one end of the network There is the receiver at the other end of the network Now how many packets should the sender send at a time before the sender waits for the acrolegement to come back? At one extreme you can send one packet wait for the acrolegement Then send the next packet wait for the acrolegement At another extreme you might be able to send hundreds of packets or all the packets at the same time and Maybe some of them will reach some of them will not reach wait for the acknowledgement and so on so what is a systematic way of Slowly increasing the number of packets that can be sent along the pipe Take a moment to think about this and when you're ready, then we can move on after the reflections part Okay So some of you may have thought that it would be useful to Send a number of packets and if the acrolegments don't come back then we reduce the number of packets Others may have thought that we should be a little conservative We should send a few packets first and if the acrolegments reach then we can send a few more packets and so on Both these ideas are correct. Actually what TCP does is a mix of both of them. There are many variants of TCP In one of the variants essentially what it does is it starts with one packet If the acknowledgement for that packet is received back in time the next round it sends twice the number of packets Once again if the acknowledgement is received back in time in the next round it sends twice the number of packets So in that sense it grows Exponentially up to a certain point Now obviously it cannot keep on growing exponentially forever. So there is a threshold So this threshold is in technical terms called the slow start threshold and so up to that number of packets It grows exponentially and then after that it sends one extra packet in each cycle So for example If in the first round you send one, in the next round you send two, in the next round you send four, in the next round you send eight And if eight is the threshold After eight in the next round you send nine, in the next round you send ten, in the next round you send twelve And you go on with this process till either you have finished the transmission Or at some point some acknowledgement does not come back within the expected time How does TCP know how much time to wait for the acknowledgement? That again is a new concept which is called the retransmission timeout So at this point we can just think of it as a predetermined time that TCP waits for the acknowledgement to come back If the acknowledgement does not come back in time then once again it starts, it drops the values And it starts again from a smaller value of number of packets to be sent So in this manner what TCP tries to do is it tries to utilize the network bandwidth optimally in sending the packets from the sender to the receiver So to summarize We have the three steps in the entire process One is the connection setup where there is a connection which is established between the sender and the receiver Then there is the data transmission Within the data transmission we have this notion of increasing the number of packets by doubling them up to a certain threshold And then increasing them linearly till the entire transmission is complete And then after the transmission is complete there is the idea of tearing down the connection or terminating the connection So that the sender and receiver, those ports and the sender and the receiver are now free to be used for other connections So this is the way in which TCP ensures that packets are delivered reliably and without errors or without loss Such applications, so there are a number of applications that use TCP as the underlying thing In any application where the loss of some information would be crucial would typically be built on TCP