What is the window size of TCP pipelined sending?

We know that instead of sending a packet and waiting a RTT then sending another (stop and wait), TCP uses pipelined sending as picture below shows: So, my question is, what's the maximum number of packets that can be sent in the pipeline without considering flow control and congestion control (what's the window size of TCP pipelined sending)?

This isn't a great question. The diagrams, above, express a fundamental misunderstanding of how IP and TCP operate. We're not concerned with when any given bit of any IP packet arrives. Additionally, the relationship among the above diagrams seems nonsensical. I suggest readers make more of an effort to understand how TCP functions before trying to characterize it using their own terminology.

Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.

2 Answers 2

so my question is, how many packets can be send in the pipeline (what's the window size of TCP pipelined sending)

There is no single answer for that. The window size changes as the receiver sends ACKs back to the sender. It is up to the receiver as to the window size, which is based on octets, not segments.

Flow Control:

TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.

That really does not make any sense because the window is the flow control. That is the reason for the window. The receiver will set the window, and it can be very large, or even set to 0 .

You cannot ask about the maximum packets (really segments, not packets). TCP is a stream protocol, and it measures in octets. Different segment can be of different sizes. "does TCP has a standard to allocate a fixed size for sender's and receiver's buffers?" No, it does not. TCP has the receiver set the window size in the SYN and modify it on the fly in the ACK.

File transfer is not the only thing for which TCP is used. Remember that your web browser uses TCP for transporting HTTP, and the segments can be of wildly different sizes for that. TCP is used when reliability is required, and you cannot simply think that each segment is of the maximum size, and TCP does not assume any such thing.

"But then it means receiver can configure its own buffer size and set it to whatever it wants for example, 10mb or even 1gb which is not practical?" Yes, that is the case. The receiver can set its receive window to what it wants, up to the limit imposed by the Window field size (16 bits will be zero to a maximum of 65,535). It is up to the host OS, but OS-specific implementations are off-topic here. "Window: 16 bits The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept."