Ask Your Question
0

Best way to calculate zero window recovery time

asked 2020-09-22 14:17:05 +0000

Monitoring gravatar image

Hi,

I often see that one end will send multiple zero window packets before it sends a non zero window update. For example when calculating recovery time should I take the delta between the first outbound zero window and the first outbound non zero window update or the last outbound zero window and the first non zero window outbound? It seems that it should be the first to me but then at times the delay is quite high.

cheers

edit retag flag offensive close merge delete

Comments

Hi,

Good day. This is purely dependent on the receiver's application side. Zero Widnow recovery may vary during the transaction, so in my opinion it doesn't matter which receiver's generated packet you will use it for calculating the recovery delta.

Best Regards, Denzil D'Souza

ddsouza gravatar imageddsouza ( 2020-09-22 14:35:29 +0000 )edit

It makes a substantial difference. Consider the below. 12:03:04.283775 10.7.10.153 10.7.10.76 TCP 54 [TCP ZeroWindow] 55007 → 3306 [ACK] Seq=2339562880 Ack=4205004478 Win=0 Len=0

12:03:04.505102 10.7.10.76  10.7.10.153 TCP 60  [TCP Keep-Alive] 3306 → 55007 [ACK] Seq=4205004477 Ack=2339562880 Win=330 Len=0

12:03:04.505114 10.7.10.153 10.7.10.76  TCP 54  [TCP ZeroWindow] 55007 → 3306 [ACK] Seq=2339562880 Ack=4205004478 Win=0 Len=0

12:03:04.952973 10.7.10.76  10.7.10.153 TCP 60  [TCP Keep-Alive] 3306 → 55007 [ACK] Seq=4205004477 Ack=2339562880 Win=330 Len=0

12:03:04.952986 10.7.10.153 10.7.10.76  TCP 54  [TCP ZeroWindow] 55007 → 3306 [ACK] Seq=2339562880 Ack=4205004478 Win=0 Len=0

12:03:05.555811 10.7.10 ...
(more)
Monitoring gravatar imageMonitoring ( 2020-09-22 14:53:03 +0000 )edit

Another way to look at this is that there is no such thing as a TCP ZeroWindow packet. (ducks)
These packets happen to meet the Wireshark rules for setting the TCP Analysis flag for tcp.analysis.zero_window

/* ZERO WINDOW
 * a zero window packet has window == 0   but none of the SYN/FIN/RST set
 */


"will send multiple zero window packets"
Those aren't multiple "zero window packets". They are ACK packets for the TCP Keep-Alive messages and happen to have a Zero Window size so Wireshark TCP Analysis flags them.

Chuckc gravatar imageChuckc ( 2020-09-22 17:04:15 +0000 )edit
add a comment

1 Answer

Sort by » oldest newest most voted
0

answered 2020-09-22 16:04:37 +0000

Jim Aragon gravatar image

The start of the Zero Window condition was when the receiver sent the first Zero Window packet. The other Zero Window packets are repeating that notification. So, you should take the time from the first Zero Window packet to the first packet with a non-zero window size.

If your Time column is still set to the default (Seconds Since Beginning of Capture), you can right-click on the first Zero Window packet and click "Set/Unset Time Reference." That makes that packet a new time-zero point. You can then just look at the time on the Window Update packet and see how much time has elapsed.

edit flag offensive delete link more

Comments

Thanks Jim. That's what I figured. In general does the trace show Keep Alive packets or are they really receive window probe packets?

cheers

Monitoring gravatar imageMonitoring ( 2020-09-23 05:16:03 +0000 )edit
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2020-09-22 14:17:05 +0000

Seen: 352 times

Last updated: Sep 22 '20

Related questions

What does a TCP zero window message implies?