TCP sliding window with fallback N-Stitch protocol

Go TCP Sliding Window Protocol/1-bit Sliding window protocol/Back N protocol/select retransmission protocol

2014-1-5 Read 884 comment 0

This article turns from http://www.cnblogs.com/ulihj/archive/2011/01/06/1927613.html

Sliding Window Protocol

A picture wins thousands of words, look at the following diagram, simple explanation under:

Both the sending and receiving parties maintain a sequence of data frames, called Windows. The sender's window size is determined by the recipient to control the sending speed so that the receiver's cache is not large enough to cause overflow, while controlling traffic can also avoid network congestion. The 4,5,6 data frame in the figure below has been sent out, but the associated ack,7,8,9 frame is waiting to be sent. It can be seen that the window size of the sending side is 6, which is informed by the receiving side (in fact must consider the congestion window CWnd, here for the moment consider Cwnd>rwnd). At this point, if the sender receives a 4th ACK, the left edge of the window shrinks to the right, the right edge of the window expands right, and the window is "sliding" forward, that is, data frame 10 can also be sent.

The following is a more detailed description of the Sliding window protocol, where the sender window size is 2 and the receiver size is 1 for the sake of simplicity. Look at the following picture:

1: The initial state, the sender has no frame emitted, send the window along the front and back coincident. Receiver No. 0 window opens, waiting to receive frame No. 0, 2: The sender opens window No. 0, indicating that 0 frames have been issued but is still confirming the return information. At this time the receiving window state is unchanged, 3: The sender opens the 0, 1th window, indicating that 0, 1th frames are waiting for confirmation of the column. At this point, the number of Windows opened by the sender has reached a specified limit, and the sender pauses to send a new data frame before the new acknowledgement returns the frame. The receiving window is still unchanged at this time; 4: The receiver has received frame No. 0, window No. 0 is closed, window 1th opens, indicating that it is ready to receive frame number 1th. At this time the sending window state is unchanged; 5: The sender receives a NO. 0-frame acknowledgement from the receiving party, closes the No. 0 window, and removes frame No. 0 from the re-publication. At this point the receive window state remains unchanged 6: The sender continues to send frame 2nd, window 2nd opens, indicating that frame 2nd is also included in the list to be confirmed. At this point, the sender opened the window has reached the specified limit, the sender will pause to send a new data frame before the new confirmation return frame, the receiving window state is still unchanged; 7: The receiver has received frame 1th, window 1th is closed, window 2nd opens, indicating that it is ready to receive frame number 2nd. At this time the sending window state is unchanged; 8: The sender receives a confirmation message received from the receiving party at Frame 1th, closes window 1th, indicating that frame 1th is removed from the re-publication. The receive window state remains unchanged at this time.

1-bit Sliding window protocol it's just that. Sliding Window ProtocolTheory, and it is different in practical application. The first is stop-and-wait Protocol (stop-and-wait), the receiver's window and the sender's window size is 1, 1 bits is enough to represent, so also called the 1-bit sliding window protocol. The sender can send only one at a time, and must wait for the ACK of the packet to send the next. Although the efficiency is relatively low, bandwidth utilization is significantly lower, but in the network environment is poor, or the bandwidth itself is very low situation, still applicable. Look at the following flowchart:

Back N protocolAlthough the implementation of the protocol is simple, it can also be applied to the poor network environment, but obviously the efficiency is too low. So with the fallback N protocol, which is also the real use of the sliding window protocol, where the window size is N, the receiver's window is still 1.      Look at the following figure, here is assumed n=9: the first sender to send 10 data frames in one breath, the front two frames correctly returned, the data frame 2 error occurred, the sender was forced to resend 2-8 of the 7 frames, the receiver must discard the previously accepted 3-8 of these frames. The benefit of the back N protocol is undoubtedly improved efficiency, but once the network situation is bad, it will result in a large amount of data re-send, instead of the above to stop the Protocol, in fact, this is very common, specifically can refer to TCP congestion control.

Select Retransmission Protocol Another problem with the back N protocol is that when there is an error frame, it is always necessary to re-send all frames after that frame, without a doubt that the network condition will deteriorate further when the networks are not very good.

the retransmission protocol is used to solve this problem. The principle is also very simple, the receiver will always cache all the received frames, when a frame error, only requires the retransmission of this frame, only if all the frames after an ordinal is received correctly, will be submitted to the high-level application together. The disadvantage of retransmission protocol is that the receiving end needs more cache.

TCP sliding window with fallback N-Stitch protocol