On 2/20/07, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
Hi List!
As I'm not an expert on TCP, I have a problem which seems to be related
to the TCP's ZeroWindowProbe mechanism. As I digged deeper into the
docs, I've found a difference between our Wiki and the TCP RFC (well,
and a lack of knowledge on my side on this topic).
To quote our Wiki
http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers: "TCP
ZeroWindowProbe <http://wiki.wireshark.org/TCP_ZerowindowProbe> - The
sender is testing to see if the receiver's zero window condition still
exists by re-sending the last byte of data to elicit a duplicate ACK
from the receiver. If the window is still zero, the sender will double
his timer before probing again."
I read this as: the sender sends the last already ACK'ed ("old") byte
again and the receiver ACKs this "old" byte just again (usually the same
ACK and Windows Size values than in the "last ACK packet").
This is in contrast to the part of RFC 793 which states (fourth section
under "Managing the Window"):
The sending TCP must be prepared to accept from the user and send at
least one octet of new data even if the send window is zero. The
sending TCP must regularly retransmit to the receiving TCP even when
the window is zero. Two minutes is recommended for the retransmission
interval when the window is zero. This retransmission is essential to
guarantee that when either TCP has a zero window the re-opening of the
window will be reliably reported to the other.
When the receiving TCP has a zero window and a segment arrives it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).
I read this as: the sender sends a single *new* byte but the receiver
ACKs the "old" byte again (usually the same ACK and Windows Size values
than in the "last ACK packet").
So about the following things I'm a bit unsure about:
- which byte does the sender send? The last old byte again or a new byte
in the stream?
It sends a new byte.
- will the ACK number of the receiver be increased because of the zero
The ACK will be increased to cover the new byte IFF the zero window
condition has ceased (windows have been opened)
The ACK will be a repeat of the previous one, repeating the ACK prior
to the ZeroWindowProbe if the receiver still ahs a zero window
condition and could not handle/accept the new byte.
window probe byte? (I wouldn't expect it that way - as the Windows size
is 0, the receiver don't have space even for this byte)
Correct.
So if the window is still zero, the ACK will indicate this by NOT
advancing to cover the new byte.
If the window is no longer zero, the receiver can handle the byte and
the ACK will be advanced to cover the new byte.
If anyone with some more knowledge on this could share some light, it
would really be helpful (Ronnie?) ...
I will fix the WIKI when i get to a more modern computer than my home
one. Konqueror 3.0 does not like wiki things :-(
