When examining network performance issues at a client site, we captured TCP traffic showing a consistent pattern of duplicate ACKs (acknowledgments) triggering retransmissions and out-of-order packets. The Wireshark screenshot reveals multiple duplicate ACK records from client (.26) to server (.252), with the problematic machines typically showing three duplicates while functioning machines show at most one.

The environment consists of:

• Server: Windows Server 2003
• Clients: Enterprise-managed Windows XP (with Symantec AV)
• Connection: 1Gbps WAN (underutilized, 56ms RTT, 0% packet loss)

The key symptom is perceived slow data transmission despite available bandwidth, with 20+ machines affected while two network operations team machines function normally.

Duplicate ACKs typically occur when:

• Packets arrive out of order (TCP seq 101 arrives before seq 100)
• Middleboxes (firewalls, proxies) modify packet flow
• Receiver buffer issues cause temporary inability to process packets
• Network stack implementation differences (especially TCP/IP stack tuning)

The fact that only non-admin machines exhibit this suggests group policy or local configuration differences affecting TCP behavior.

To investigate further, we can use PowerShell to check TCP settings on affected vs working machines:

# Check current TCP parameters
Get-NetTCPConnection -State Established | 
    Where-Object { $_.RemoteAddress -eq 'server_ip' } |
    Select-Object Local*, Remote*, State, AppliedSetting

# Compare with known good machine (replace with actual values)
$goodSettings = @{
    'TcpAckFrequency' = 1
    'TcpMaxDupAcks' = 2
    'InitialRTO' = 3000
}
Get-NetTCPSetting | Where-Object { $goodSettings.ContainsKey($_.SettingName) }

Since modifying TcpMaxDupAcks on the server (Windows 2003) proved limited (valid range 1-3), we should focus on client-side adjustments:

# Potential registry tweak for Windows XP clients
$tcpParams = @"
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDupAcks"=dword:00000002
"TcpAckFrequency"=dword:00000001
"EnablePMTUDiscovery"=dword:00000001
"@
$tcpParams | Out-File -FilePath ".\TCP_Tweaks.reg"

Additional areas to examine:

• Compare NIC driver versions between working/non-working machines
• Check for QoS policies applying differently to user groups
• Test with Symantec AV temporarily disabled (known to sometimes interfere with TCP window scaling)
• Capture traffic at switch level to rule out local machine artifacts

For applications where you control both ends, consider implementing application-level acknowledgments:

// C# example of simple reliability layer
public class ReliableUdpSender {
    private Dictionary<int, DateTime> _sentPackets = new();
    private int _nextSeq = 0;
    
    public void SendReliable(byte[] data) {
        var packet = new ReliablePacket {
            Seq = _nextSeq++,
            Data = data
        };
        _sentPackets[packet.Seq] = DateTime.Now;
        SendUdp(Serialize(packet));
        
        // Start ACK timeout check
        Task.Run(() => CheckAckTimeout(packet.Seq));
    }
    
    private void CheckAckTimeout(int seq) {
        Thread.Sleep(200); // Wait for ACK
        if (_sentPackets.ContainsKey(seq)) {
            // Resend if no ACK received
            ResendPacket(seq);
        }
    }
}

For wide-scale implementation in managed environments:

• Create Group Policy Objects (GPOs) to standardize TCP settings
• Build a PowerShell remediation script for non-compliant machines
• Consider deploying a custom WMI filter to target only affected client configurations

# Example GPO remediation detection script
$requiredSettings = @{
    'TcpMaxDupAcks' = 2
    'TcpAckFrequency' = 1
}

$currentSettings = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters'
$nonCompliant = $requiredSettings.GetEnumerator() | 
    Where-Object { $currentSettings.($_.Key) -ne $_.Value }

if ($nonCompliant) { exit 1 } # Trigger remediation
else { exit 0 }

In our packet capture analysis (Wireshark screenshots attached), we observe a consistent pattern where client machines (.26) send duplicate ACKs to the server (.252), triggering retransmissions and out-of-order packets. The problematic machines typically generate three duplicate ACKs, while functioning systems show at most one.

The core issue stems from TCP's fast retransmit mechanism. When packets arrive out-of-order, receivers generate duplicate ACKs for the last in-order segment. Windows XP's default TcpMaxDupAcks=2 threshold means three dup ACKs trigger retransmission.

Key contributing factors we identified:

• Network stack configuration differences between admin/non-admin machines
• Potential Symantec AV network inspection interference
• TCP window scaling behavior in mixed Windows 2003/XP environment

For Windows XP clients, adjust these registry settings (requires reboot):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDupAcks"=dword:00000003
"TCPWindowSize"=dword:00040000
"Tcp1323Opts"=dword:00000003
"TCPTimedWaitDelay"=dword:0000001e

To check current TCP settings across multiple machines:

# TCP parameter checker
$computers = "client1","client2","server1"
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters"

foreach ($computer in $computers) {
    try {
        $session = New-PSSession -ComputerName $computer
        Invoke-Command -Session $session -ScriptBlock {
            Get-ItemProperty -Path $using:regPath | 
            Select-Object TcpMaxDupAcks, TCPWindowSize, Tcp1323Opts
        }
        Remove-PSSession $session
    } catch {
        Write-Warning "Cannot connect to $computer : $_"
    }
}

Use this Wireshark display filter to isolate the issue:

tcp.analysis.duplicate_ack || tcp.analysis.retransmission || tcp.analysis.out_of_order

When examining working vs. non-working machines:

1. Run netsh int tcp show global on both systems
2. Compare output of netsh int ipv4 show dynamicport tcp
3. Check NIC advanced settings (Flow Control, Interrupt Moderation)

For Symantec Endpoint Protection, add these exclusions:

1. Network Threat Protection → Exclusions → Add:
   - Process: svchost.exe
   - Port: Your application port
2. Application and Device Control → Add trusted network applications