Share via

Default TCP window size of Windows Mobile devices

  • Article

Using remote registry tool, I can verify that the default maximum TCP window size (buffer size) of a Microsoft Smartphone 2003 emulator or a Windows Mobile 5 Smartphone emulator is 32768 (the registry key is HKLM\Comm\Tcpip\Parms\TcpWindowSize). This is not a multiply of the MSS - On Windows XP/2000, the value is 17520 = 12 * 1460, where 1460 is the MSS. But according to this article on MSDN, the TCP/IP stack will round the value to an increment of MSS that is negotiated during connection setup.

Windows CE 3.0 and up support windows scaling option, which allows a window size larger than 64K (Not the window field in TCP header is 16bit, so without window scaling option, the maximum window size is 64K).

So how does this setting affect your application's performance? MSDN says:

"...To summarize, Windows CE TCP/IP can adapt to most network conditions, and can dynamically provide great throughput and reliability on a per-connection basis. Attempts at manual tuning are often counter-productive unless a qualified network engineer first performs a careful study of data flow"

The reason I am digging into this is that someone reported poor performance accessing HSDPA (a flavor of 3G data service based on UMTS) from Windows Mobile Smartphone. A downlink of 3.6Mbit/s is expected. One possible solution is to adjust the TCP receive window size in the registry. However, if Windows Mobile (actually WinCE TCP/IP stack) has some sort of receive window auto-tuning or window scaling (both are available in Windows Vista), then this should not be a problem.

What's needed is some heuristic algorithm that keeps tracking of effective bandwidth and round trip time between peers and adjust the window size accordingly.  This can be done either on the receiver side (by estimating the pipe and compute the advertised window size for the sender) or on the sender side (by growing the window size to match the available bandwidth up to the receiver's advertised window size). If congestion control algorithms are used, the outstanding segments a sender can send is the minimal of this rwin (receive window size) and cwin (congestion window size), assuming the sender's socket buffer has enough segments to send. 

For a calculation of receive window size for HSDPA connections, see Martin Sauter's blog entry here.

Comments