Some published web applications see reduced network throughput between the client and published web servers if the applications are published through Microsoft Forefront Unified Access Gateway (UAG) 2010. This throughput is smaller compared with the throughput that is experienced by clients that access the web server directly.
This problem typically occurs during the publication of large Outlook Anywhere mail sends or SharePoint file uploads through a Forefront UAG 2010 server. However, this problem can affect any data transmissions between the client and the published server.
This problem occurs in Microsoft Forefront Unified Access Gateway 2010 Service Pack 2 and earlier versions because the Nagle algorithm was not disabled for network connections to published web servers.
Depending on the network topologies and the pattern of data packets that are sent by the client, the Nagle algorithm may cause reduced data throughput. This is because the Nagle algorithm on the Forefront UAG server and the delayed acknowledgement timer (also known as the delayed ACK timer) on the published server may cause many 200ms delays. These delays occur for the following reasons:
The Nagle algorithm lets only one small (non-full) TCP packet be outstanding on a network connection.
The delayed ACK timer lets Windows acknowledge only every other TCP packet or acknowledge a single packet only after 200ms.
If a small TCP packet is outstanding on a TCP connection, the Nagle algorithm prevents Forefront UAG from sending additional data packets. This can cause a delay because the published web server waits 200ms to acknowledge the outstanding packet. The cumulative effect of many 200ms delays may cause decreased throughput.
To resolve this problem, install the service pack that is described in the following Microsoft Knowledge Base article:
2744025 Description of Forefront Unified Access Gateway 2010 Service Pack 3
After you apply this service pack, Forefront UAG 2010 disables the Nagle algorithm on the sockets that it creates to the published web servers. This change is made to avoid causing the delays that are described in the "Cause" section.
To work around this problem, set the TcpAckFrequency value to 1 on the published web server. This setting causes the TCP stack on the published web server to send an ACK for every packet. This setting also lets the system ignore the delayed ACK timer.
For more information about the TcpAckFrequency value, go to the following Microsoft Developer Network (MSDN) website: