Drawing actual TCP window size in Wireshark

tcp_window

asked 2019-07-11 07:36:14 +0000

fakej
1 ●1 ●2 ●2

updated 2019-07-11 07:45:26 +0000

I'm wondering if it's possible to draw in wireshark the actual size of TCP window (amount of unacknowledged data sent). I'm aware of Statistics/TCP Stream graphs/Window scaling but to my understanding it draws maximum TCP window allowed by receiver and the actual amount of unacknowledged data sent be sender could be lower.

That's how I think it could be calculated:

If the capture was done on receiver end the window size would be amount of data sent in a time window equal to RTT.
If the capture was done on a sender end that would be amount of data sent since the last acknowledged packet.

edit retag flag offensive close merge delete

add a comment

answered 2019-07-11 09:59:01 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

I've got wonderful news for you: the field tcp.analysis.bytes_in_flight keeps track of how many bytes are were sent, but not yet acknowledged. Calculation of this field can be enabled/disabled from the TCP protocol preferences, so if you do not see this field under "SEQ/ACK Analysis", you might need to enable it first.

edit flag offensive delete link

Comments

Thanks a lot that was so simple...

Anyway it does not solve my problem I in all cases. Meaning: "If the capture was done on receiver end the window size would be amount of data sent in a time window equal to RTT." This on is not represented by tcp.analysis.bytes_in_flight. Sorry if I was not clear enough. So for example let's say the sender sent 100 packets 1500 bytes each without waiting for ack. So from the sender point of view the window is 150kB. But if the latency is high they usually won't arrive all in one go without any ACK sent in the meantime. Receiver will probably get 20 of them, ack, then next 20, ack and so on. Therefore from the receiver point of view the window will be lower. Anyway because the latency usually can be calculated it would be great to ...(more)

fakej ( 2019-07-11 10:48:56 +0000 )edit

So from the sender point of view the window is 150kB

What window do you mean? A sender is aware of 2 windows: CWND (own congestion window, internal calculated value); RWND (receiver window, reported by receiver in packets). Or you mean BDP (bandwith-delay product) estimation for a path?

Plotting Bytes in Flight on receiver side is useless in 99% cases as doesn't represent path RTT or BDP but only internal processing time maybe. Usually you'll see every other packet ACKed, so BIF is gonna be 2*MSS maximum. Sometimes it might be a bit larger depending on ACK strategy and capture point placement, but not substantially.

Packet_vlad ( 2019-07-11 11:33:29 +0000 )edit

I would like to know amount of data that has been transmitted but not yet acknowledged (acknowledgements that could have been sent by receiver but have not reached the sender don't count). And the problem is I may have only packet capture from receiver end. From my experience this is pretty well represented by the amount of data received by receiver divided by RTT. At the moment I just use the display filter to filter packets from the specific time window using frame.time property and calculate the sum of packets length for everything matching the filter (so for example sum of all packets received in 200ms if that's the latency).

So this is none of: RWND/CWND/BDP because if client uses some throttling or has limited TCP send buffer than all mentioned windows will be larger than amount of data that client sends on the network ...(more)

fakej ( 2019-07-11 12:52:00 +0000 )edit

This information is simply not available on the receiving side of the transfer. You will have to reside on the guesstimates that you are already using.

Adding guesstimate fields to Wireshark seems like a very bad idea to me :-) You could however write a Lua plugin that kind of calculaties this for you.

SYN-bit ( 2019-07-11 13:01:12 +0000 )edit

Well ok, maybe doing it part of the Wireshark is too much but external application which creates packet capture from the other end (taking into consideration RTTs, duplicates, retransmissions, etc) would be nice to have ;-)

fakej ( 2019-07-11 13:19:14 +0000 )edit

add a comment

Drawing actual TCP window size in Wireshark

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Drawing actual TCP window size in Wireshark edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Drawing actual TCP window size in Wireshark