Office Colocation WiFi Slowness with WSS Agents
Article ID: 447638
Updated On:
Products
Issue/Introduction
Corporate users accessing internet via Cloud SWG using WSS Agent access method.
A subset of users now collocating in shared offices where they must use their guest network when working from these locations.
Users at these locations are finding the speed very slow, even though speed tests and the IT team claims the guest has enough capacity.
When the WSS Agents are removed from a test machine, applications like Jira and Microsoft admin portals loaded as expected with no delays or time outs.
It seems that slowness only exists with the combination of WSS Agent and the guest network.
Environment
Guest Wifi network.
WSS Agent.
Cloud SWG.
Cause
Guest Wifi network reducing MTU and causing IP fragmentation.
Resolution
Force TCP as transport for the tunnel using the following wssad parameter (note that CMD must be run in administrator mode, and tamper detection must be disabled in Cloud SWG Portal).
C:\Windows\System32>"C:\Program Files\Symantec\WSS Agent\wssad.exe" -p enableUDP=false
To check whether the parameter is enabled or not, check out "HKLM\SOFTWARE\Symantec\WSS Agent" registry entries.
Additional Information
The issue was clearly related to the Wi-Fi network being accessed, and tethering laptop via the users phone/mobile network had no issues.
Suspecting an MTU issue (many tunneled protocols over UDP will have overhead which may be exacerbated with security settings on Wi-Fi), tests were carried out reducing the MTU size for the Wi-Fi interface on Windows and this showed promise when it was reduced to about 1420.
UDP is a "fire and forget" protocol. It has no mechanism to track if a packet arrived safely or to request a retransmission. If Wi-Fi jitter or interference drops just one piece of that fragmented UDP packet, the destination router cannot rebuild it. Because it's UDP, it won't ask for a re-send. The entire payload vanishes, leading to immediate packet loss, dropped VoIP calls, audio stuttering, or broken web streams and performance related problems.
TCP is a different beast, and actually handles MTU issues transparently via the path MTU algorithm which is why this worked. With TCP, if we send a segment that needs to fragmented due to MTU differences, the interface that needs to fragment the packet will send an ICMP response back (fragmentation needed but DF bit set) with the largest MTU. The client then changes the amount of TCP data it sends, so that we have no issues.
As long as the network is solid, there will not be much difference between TCP and UDP perf .. When network is not stable there will be a huge difference.
Feedback
