What is a TCP flow and the difference with TCP window?

[George-Sl]

At first I have some questions about TCP window,

1. "TCP window" is chance(or a window) to send consecutive bits of data without need of acknowledge in a limit of windows size, am I right?

2. okey let's assume that the windows size of our tcp connection is 200 kb, if we successfully transfer 195kB data(of segments), and suppose the last segment size that is left to send is about 10 kB, then what will happen? the segment will be cut?

3. What is a "TCP flow"? is it a networking term or it's just mean flowing of a tcp packet?? what is the difference between TCP window and TCP flow?

thx

[Philip D'Ath]

1. Yes.

2. Up to the host implementation of the TCP stack.  It may wait for the application to flush out the buffers on that connection (or close the connection), or the stack may wait a specific amount of time, of the stack may decide not to do buffering and just send what it has available.

3. It's a network term referring usually to a layer 4 stream of packets between two hosts.

[Joshua Messenger]

TCP windowing is a congestion avoidance mechanism that facilitates allows the receiving system to reduce its window size such that the NIC buffers and or OS buffers are not overrun.  The default TCP windows is 65535 bytes and for it to be different a person must change the parameters.  In windows it would be changed with regedit.exe  In unix there are various locations.

For more information about TCP window optimization take a look at:

http://baud9600.com/Calculators/TCP-Optimal-Window-Size-Calculator.html

A TCP flow is the end to end connection and how the data flows through the network.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

#1 As also noted by Phillip, yes.

#2 TCP should wait until there's buffer space available to send next TCP segment.  As noted by Phillip, there's likely a timer that will generate a error, if RWIN doesn't increase to accept new TCP segment with a certain amount of time.

#3 It's the TCP session between two hosts.  Multiple TCP packets with the same IPs and ports.  Also think of TCP's 3 way handshake.

TCP window is a send or receive buffer.  Receiver advertises how much buffer space it has to store TCP segments (RWIN).  TCP sender has congestion window, allows for how much the sender will transmit without an ACK.

[chao.jiang0517]

Hello! So regarding TCP flow how shall I understand that also thinking of TCP 3 way handshake? Do you mean that a TCP flow includes all the pkg from 3-way handshake to 4-way close?

Since when using follow TCP flow in wireshark the pkg shown/remained are not at all a full process from 3 way start to 4 way close but just few with ACK flag. That makes me think that one flow shall be just one data trasfer of request and reply between 2 hosts. Is that correct?

Thank you!

[Joseph W. Doherty]

"So regarding TCP flow how shall I understand that also thinking of TCP 3 way handshake? Do you mean that a TCP flow includes all the pkg from 3-way handshake to 4-way close?"

Yes, correct.  From TCP handshake to close you have a TCP session, and the packets used by that session are part of the same "flow".  Further, I would say a "flow's" packets are just considered those from one host to the other.  I.e. ACKs, although used to "manage" the flow, are generally not thought as part of the "flow".  The latter because ACKs (ignoring piggy back ones) are often such low bandwidth consumption compared to the packets they are ACKing.

It's certainly possibly, that since TCP does create a two way session, both hosts can be sending data to the other.  In this case, although there's only one TCP session, normally, you would consider this as two flows.

Also remember, another reason flows are "flows", they are directional, because routing is directional.  I.e. packets flowing in one direction do not have to be on the same path in the reverse direction.

Unsure I understand your second paragraph, but TCP, itself, has no concept of request and/or reply.  That's for a higher level of the stack.

[chao.jiang0517]

Hi Joseph thanks for the reply! Forgive my nonsense in the 2nd paragraph. What I meant is the packages I found in my wireshark after applying a "Follow TCP flow" have only TCP ACKs but no 3 way start and 4 way close. That made me think a TCP flow is not what you explained before but, when checking again they are all the packages exchanged between my host and a remote one, only that the 3 way start and 4 way close packages are not captured (as Giuseppe speculated). 

Now everything is clear and thanks again for the explanation! 

[Giuseppe Larosa]

Hello @chao.jiang0517 ,

because there are separated 32 bit filelds for Sequence number and Acknowledge fileld one packet in one direction A -> B can be used at the same to ack traffic travelling in direction B -> A and to send some data in direction A -> B.

This is called piggy backing ( having an ACK field in a packet  and data for the reverse direction).

each sender has to respect the advertised TCP window from the the other side ( the receiver).

Your packet capture may be incomplete or for the way traffic is mirrored you may be seeing only one direction.

Hope to help

Giuseppe

[chao.jiang0517]

Hi Giuseppe thanks for the reply!

Indeed as I replied to Joseph the pkgs I got after applying "Follow TCP flow" are all exchanged between my host and the remote one, and the 3 way start and 4 way close somehow are lost. Now things are clear and thanks for the explanation of piggyback which is new to me!