Possible TCP Issue?

I was troubleshooting user complaints of an app performing slowly across the WAN.

I observed the user try to load up a database in the app, and it did indeed take forever. About 3.5 to 4 minutes to load. The entire time, just waiting at a spinning screen.

I ran pcaps on both ends while it was loading.

Not sure what I expected to see, probably tons of drops and retransmits etc

Instead what I was greeted with was this:

The entire time the user sat waiting for the app to load, the server and client were busy constantly exchanging packets. There was no hanging, no gap in packets.. i.e. no "silent periods." Just a constant, steady clockwork stream of tiny, tiny 50-100 Byte packets sent by the Server, each one ACK'ed by the client.

Are you kidding me? What the hell?

Not a single packet was lost or arrived out of order, etc. The TCP Dump looked beautiful. Very clean. It just so happened to take absolutely FOREVER for the entire load to be sent over to the client, because it was sending such small packets and waiting for an ACK from the client before it sent the next one. With a mere 100ms of latency, this led to literal 4+ MINUTE waits to load any screen.

This.. has to be a TCP Windowing issue, right? If the server could send 1526 byte packets then it'd complete 60% faster.

I observed the client load a few other apps like Outlook and Web, and window scaling seemed to work like normal. Same for on the server. Without getting into Windows TCP Window settings, I observed normal window scaling behavior on both client and server.

SO... what gives? Is this just how the application is designed? I don't really understand what's going on here.

I'm guessing I might have to dig into registery editor and start messing with TCP settings for Windows?

It's clear to me if the server could send typical 1526 or larger byte packets the operation would probably complete 60% faster...