An interesting connectivity issue or two

[Tarjei-stavanger]

It might be worthwhile to check for this decrepancy. It has been discovered due to the Visma Resursstyring application which probably asks for far too much data.

I just noticed that SQL server 2022 on a virtual Windows server 2022 seems to disregard the Network Packet Size setting for the TDS protocol. Note screenshots below. The setting is 4096 bytes and many of the packets that is sendt is well beyond the IP4 packet reassemply buffer on the Windows 11 client. Possibly also an issue for the VMX3net network driver on the server. Windows 10 seems to cope. I'm working to determine if this is really a big probem and then how to fix this.

I have an open case with Microsoft support regarding the issue.

When we run TSS.ps1, the Windows 11 clients works just fine. This lasts until the PC is rebooted, then its back to misery. As I wrote, I'm working to find the fix. We can't run TSS.ps1 every time we want to use that application. This is another case I have open with Microsoft.

I suspect hat the "fix"exists either because of the 2024-11 patch or a newer TSS.ps1. It didn't work that way earlier.

[Malcolm-Stewart]

The 4096 byte packet size in SQL Server is just a default. Some drivers ask for an 8000 byte packet. And you can also override by explicitly setting the Packet Size in the connection string. SQL Server supports packet sizes up to 32K (32767) on an unencrypted packet and up to 16K (16383) on an encrypted packet. A few bytes less, if MARS is enabled. This will be split by the network into several frames of up to 1500 bytes on a normal network or larger if Jumbo Frames are implemented.

But what you present in the network capture image with a packet length of 200K seems to be more of a TCP optimization than a SQL Server packet size issue. This appears to be showing the Large Send Offload optimization, where TCP packet segmentation and reassembly is performed by the NIC card. Because the NIC card exists below the network trace driver, the trace sees the full, unsegmented packet. To see the segmented traffic, you would have to trace at the switch level or on some other device on the network.

Here's a link:
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/offloading-the-segmentation-of-large-tcp-packets

[Tarjei-stavanger]

If the driver of the sending machine assembles packet before transmission, it should not visible to WireShark. For TCP, the largest segment for LSO is supposed to be 64K.

As can be seen in the screenshot, the largest packet is 261 384 bytes. It is being sendt from the machine with SQL server. And it is way larger than the default TCP reassemble buffer on the client. About twice as large.