TCP rwindow exceeded after SACKs

Hi!

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
Windows.

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
https://bugzilla.mozilla.org/show_bug.cgi?id=541367#c31

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:
http://tools.ietf.org/html/rfc2018#section-5
"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.

Greetings,
Martin von Gagern