A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » Networking and the Internet with Windows XP
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

TCP rwindow exceeded after SACKs

Thread Tools Display Modes
Old May 6th 11, 01:12 PM posted to microsoft.public.windowsxp.help_and_support,microsoft.public.windowsxp.network_web
Martin von Gagern
external usenet poster
Posts: 1
Default TCP rwindow exceeded after SACKs


Dunno if this is the right place, but once more I've hit the bizarre
fact that there seems to be no clear and cost-free way to report bugs in

Is it likely that Microsoft employees will read this here? If not, do
you know of any other place where such a technical report would be
accepted free of charge, obviously without any guarantees of a fix?

This time I've encountered what appears to be a bug in the TCP
implementation: when receiving selective acknowledgement (SACK) packtes,
the TCP implementation of windows will send more data than the recipient
is willing to accept.

Originally report is he

Steps that lead to the bug, with the client on a Windows XP system:
1. Client enables a larger send buffer via setsockopt(SO_SNDBUF)
2. Client establishes a TCP connection without window scaling
3. Client sends a large amount of data to the server
4. Connection looses a packet
5. Server sends ACK for all up to the lost packet, and includes SACK
information for subsequent received packets
6. Client retransmits lost packet, and continues sending new data
7. Retransmission perhaps got lost again, or at least delayed a bit
8. Client transmits data even past one server receive window size after
the last ACKed packet
9. Server resets connection

I guess that in 8., Windows incorrectly doesn't consider the SACKed data
as part of the "in flight" data amount. But that data cannot be relayed
to the server application yet, so it does occupy buffer space on the
receiving side, so it does in fact fill (part of) the receive window.

With access to the source code, I would believe it should be easy enough
to change the calculation of the amount of data we may send to handle
SACKed packets correctly, i.e. calculate the sequence number of the last
byte we may legally send based on the last received ACK, without any
regard to additional SACK information we may have received.

It could even be that Windows already removed the SACKed packets from
its send buffer, although the RFC forbids such behaviour:
"A segment will not be dequeued and its buffer freed until the left
window edge is advanced over it."
But as the send buffer socket option appears to play a role here,
windows probably keeps the data all right, but simply doesn't count it.

As a workaround, one can disable SACK support completely:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\SackOpts=(DWORD)0
This can however reduce performance, as unneccessary retransmissions
will waste uplink bandwidth.

I wonder if there is any chance of getting Microsoft to distribute a fix
to this issue, which might cause more and more connections to break the
more applications are ready to employ larger send buffers.

I'll try to follow the news groups these next few days, but if in doubt,
you have better chances of getting a reply from me if you send it to my
e-mail address as well.

Martin von Gagern

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

All times are GMT +1. The time now is 05:07 AM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.
Copyright 2004-2023 PCbanter.
The comments are property of their posters.