A couple of weeks ago I posted a note asking for any information on
Microsoft's support of TCPLW and related options in their Windows 98 beta.
Since then, several of you have responded with interest about what I have
found.
To date, I have tested both the Windows 98 and Windows NT 5.0 beta's with
the basic test setup described below without success.  I should preface this
by saying that I do not claim expertise in the area of transport protocols
(or the fine art of "tweaking" TCP options).  My informal tests are being
conducted to see if commercial file transfer products (using the new TCP
extensions) can replace custom file transfer software for use between the
Space Shuttle & Space Station laptops and the Mission Control Center (1.3s
RTT).
TEST SETUP:
My test set up includes a "local" and a "remote" computer (both IBM Thinkpad
760 XDs w/ 3Com Etherlink III PCMCIA Ethernet Adapters) each with the
Windows NT 5.00.1671 (beta) loaded.
The computers are connected via Ethernet routers (Both NT servers running
Steelhead Router S/W) as shown below.  Note that the Routers contain a
custom satellite communications card with an NDIS driver - such that it
appears to be an Ethernet card to the Router software.  These communications
boards can be configured to various transmit rates including 128 Kbps, 2
Mbps, and 4 Mbps.  For these tests, both forward and return links were
configured to 4 Mbps.
Local PC---Local Router---Satellite Link Simulator---Remote Router---Remote
PC
or
PC---10 Mbps Ethernet---4 Mbps bi-dir. link w/ 1.3 sec RTT---10 Mpbs
Ethernet---PC
Our Satellite Link Simulator can be set to "delay" (0.65 sec each way) or
"bypass" for both forward and return links.  Additionally, it can be
configured to introduce bit errors into the link.  For these tests, I used
no bit errors, and used both "delay" and "bypass" link configurations.  
I am testing the throughput by using FTP software (WFTPD.exe server and
WS_FTP client) to transfer a 20MB file across the link.  I used this
software for a couple of reasons.  It is a commercial implementation and, by
using a socket spy program, I determined that the application is not
specifying a specific window size (therefore, it should use the default
large window size).
WINDOWS 98 BETA TEST SETTINGS
The following are the TCP registry settings used on the Windows98 PC's on
both sides of the link:
        
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP
        DefaultRcvWindow = 650000 (DWORD) - based on 1.3sec*4Mbps
Hkey_Local_Machine\System\CurrentControlSet\Services\Class\netTrans\ 000n
        MaxMTU = "1400" (string) - assumed to be reduced from the default
1500 
And even though these are supposed to be the defaults, I entered them
anyway:
Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP\Parameters
        Tcp1323Opts = "3" (string) - Window scaling and Time stamp options
enabled
        SackOpts = "1" (string) - SACK enabled
        MaxDupAcks = 3 (DWORD)
WINDOWS NT 5.0 BETA TEST SETTINGS
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
        TcpWindowSize = 650000 (DWORD) - based on 1.3sec*4Mbps
        
Hkey_Local_Machine\System\CurrentControlSet\Services\ELPC3R\Parameters\Tcpip
\
        MTU = 1400 (DWORD) - assumed to be reduced from the default 1500
                (Note: ELPC3R is the Ethernet adapter name)
And even though these are supposed to be the defaults, I entered them
anyway:
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
        Tcp1323Opts = "3" (string) - Window scaling and Time stamp options
enabled
        SackOpts = "1" (string) - SACK enabled
        MaxDupAcks = 3 (DWORD) 
RESULTS
For BOTH tests, when using FTP with the link in "bypass" mode (no delay), I
was able to achieve almost the full 4 Mbps data transfer rate (~3.6 Mbps).
Not surprising, since this would simulate normal Ethernet.   However, when I
placed the link in "delay" mode, the rate dropped down to ~ 40 - 60 Kbps.
This is where I expected the TCPLW to kick in.
I was able to monitor the Router throughput traffic using NT Performance
Monitor and thus see the packet traffic and Xmt/Rcv bit rates over the
Routers.  With the delay, I can clearly see the dead space between packets
and the acks.  I don't seem to be seeing any increase in the sliding window
size.
I was able to contact a project engineer with Microsoft to try to verify my
TCP option settings.  When I shared my Win98 test results with him, he
informed me that due to a "memory manager" problem, Win98 TCPLW options may
not be functional.  He advised me to try NT 5.0 beta.  Once again, I
verified my TCP option settings and then reported back my unsuccessful
findings.  Since then, he referred me to Microsoft's Technical Help.
Unfortunately, they do not support beta products.
I feel that I am very close to a successful test, but may have some minor
(or major) TCP configuration problems.  
If anyone can see any glaring (or not so glaring) problems with my test
setup, I would appreciate the feedback.  Additionally, if anyone has any
contacts with the Microsoft engineers that implemented these options, I
would be interested in their feedback.
Thanks,
Steve Rader  
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:35 EST