What is confused window syndrome?

Http://www.cnblogs.com/ggjucheng/archive/2012/02/03/2337046.html

What is confused window syndrome?

When the sending application process produces slow data, or the receiving application process processes slow data in the receiving buffer, or both, the packet segment transmitted between application processes is very small, especially the payload is very small. In extreme cases, the payload may only have 1 byte, while the transmission overhead may be 40 bytes (20 bytes of IP header + 20 bytes of TCP Header). This is called confused window syndrome.

Confused window syndrome caused by sending end

If the sender serves applications that produce slow data (typically Telnet applications), for example, one byte is generated at a time. This application writes one byte of data to the TCP cache of the sending end at a time. If the sending end does not have a specific command, it generates a packet segment that only contains one byte of data. As a result, many 41-byte IP data packets are transmitted over the Internet.
The solution is to prevent the sender from sending data in bytes over TCP. The sender must force TCP to collect data and use a larger data block to send the data. How long does the sending end wait for TCP? If it waits too long, it will cause a long delay throughout the process. If the waiting time is not long enough, it may send a small packet segment. Nagle found a good solution and invented the Nagle algorithm.

Confused window syndrome caused by Acceptor

TCP at the receiving end may produce confusion window syndrome if it serves applications that consume slow data, for example, consuming one byte at a time. It is assumed that the sending application generates 1000 bytes of data blocks, but the receiving application only absorbs 1 byte of data each time. Then we assume that the TCP input cache at the receiving end is 4000 bytes. The sender sends the first 4000 bytes of data first. The acceptor stores it in its cache. The cache is full now. The notification window size is zero, which indicates that the sender must stop sending data. The receiving application reads the first byte of data from the TCP input cache at the receiving end. The cache contains 1 byte of space. The receiver's TCP announces that its window size is 1 byte, which indicates that TCP is eager to wait for the sender to send data to regard this announcement as good news, and sends packets that only contain one byte of data. This process continues. One byte of data is consumed, and then a packet segment containing only one byte of data is sent.

For this confused window syndrome, that is, the application consumes less data than it arrives, there are two suggested solutions.
1 Clark solution is to send confirmation as long as there is data arriving, but the declared window size is zero until or the cache space can be placed in the maximum length of the packet segment, or half of the cache space is empty.
2. Delay confirmation the second solution is to wait for a period of time before sending confirmation. This indicates that confirmation is not sent immediately when a packet segment arrives. The receiving end waits until there is sufficient space in the cache. Delayed confirmation prevents the sender from sliding its window over TCP. When the sending end sends the data, it stops. This prevents such symptoms.
Delayed Validation also has another advantage: It reduces traffic. The receiver does not need to confirm each packet segment. However, it also has a disadvantage that delayed validation may force the sender to re-transmit unconfirmed packets.
The protocol can be used to balance this advantage and disadvantage. For example, the latency defined for validation cannot exceed 500 milliseconds.