SP2, proxy; largish (>~1-3Meg) download probs; TCP/IP shrinking RCVwindow

M

Ms. Linda A.W.

I just got a new computer that came with SP2.

This is a technical question that has 1st-3rd level (non-redmond) support
baffled.

My windows computers are behind a proxy on an unroutable subnet. My home
subnet is in the 192.168.xxx.xxx range. With SP1 (et al.), I don't have
a problem behind the proxy, but with SP2, "larger" files stall on download
and eventually timeout. Trying to download the same file on a _peer_ SP1
system (also behind firewall) downloads files at ~300KB/s (3Mbit downstream DSL).

I compared a download of the same file (I chose a 200MB file, as there is
no chance of it working on the broken SP2) using _ethereal_ (haven't
upgraded to _wireshark_).

The symptom is reliable and noticable at the TCP/IP protocol level.
The TCP RCV window starts out with both clients, at ~64K. Download
proceeds @ full speed for a few windows, then on BOTH SP1 & SP2, the
RCV window begins to shrink with each received packet (as though the
network stack was reducing the TCP window size in response to congestion.
The window "inches" its way down: 64K->57K->53k->...17K finally down to
<1K -- maybe 600 bytes. Then the behaviors differ between SP1&2.

On SP2 (the fail case), when the window gets too small, I see some sort
of error status "TCP window full" happen on the client (in ethereal).
Then the download will hang.

Compared to an SP1 client -- it also has the shrinking window, but when
it gets down to ~1K, the SP1 client sends some type of RCV window size
reset back to the proxy server, and the RCV windows go back up to near
64K again, and downloading continues full speed (external programs think
they are getting close to a uniform 300KB/s download).

That's it -- symptom description. First, please realize, if I am desparate
enough to be measuring TCP/IP streams with a network analyzer, I've tried
the seemingly obvious things. Have checked TCPIP\Parameters concerning
MTU, window size (have tried >64K window settings), have set the TCP1323
(?whichever RFC it was for window scaling) to scale or not, have compared
settings between two machines (both TCPIP-parameters(global), and the
interface/{guid}/<specific params>.

Firewall is off. No firewall or anti-"malware" program running on the SP2
box (it's brand new and not on the internet directly). Doesn't seem to be
related to raw-socket anything limit imposed in XP2 (BTW - is that limit in
Home & Pro? Have seen some posts indicating it was different between the two).
Both computers are running "Pro".

On the SP2 machine, SMB file transfers from the proxy machine (serves files to
the inner network) appear _NORMAL_. I.e. the connections locally seem "ok" --
only largish HTTP downloads (like, say the SP2-debug-symbol download from
Microsoft's download site (the 200MB file)).

Have tried different user profiles on the SP2 machine. Nothing seems to make a
difference. Have been googling over net and MS-site. None of the "close"
scenarios mentioned seem to apply in this case.

The RCV window shrink rate is not deterministic. In fact, this problem
initially manifested by problems with Windows Update -- an MS support,
script-reader, had me download the 40+ updates from MS update, 1 at a time.
Repeated download attempts on the same binaries would, randomly, eventually lead
to success, as the patch downloads were all <2MB, and "randomly", enough
repetitions, and that size file can make it through. The 3rdlevel MS support
person said that getting the updates to download was the extent of his
knowledge, and he didn't know how to go about debugging the larger problem.
-End-of-call-.

Needless to say, I'm rather bummed with my "new computer"...sigh. Have never
had such an "unfun" time w/a new computer.

If anyone can point me at some docs or a fix so SP2, will renegotiate the RCV
window size when it gets too small (rather than just dying/hanging), it would
be VERY helpful.

I tried to load my XP(SP0) disk to install on my new system, but got
Bluescreened as soon as the install tried to boot the WinNT kernel. I'm running
out of things to try....:-(.

Help?
linda
 
D

Doug Sherman [MVP]

Check for a DWORD value called DefaultReceiveWindow in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Afd\Parameters

Reportedly this setting takes precedence over TCP/IP parameters - this
behavior is new in SP2.

Doug Sherman
MCSE, MCSA, MCP+I, MVP
 
F

Frank

If this is a PPPoE DSL your connection is timing out.
There is a setting for this somewhere but I can't
remember where, DSL was too much of a problem
for me and I went back to cable after the contract
ran out. I hope that someone with your type of setup
will chime in. It might also help to go to broadband
reports and try some of their tweak tools.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top