Squid on Ubuntu not reliably retransmitting after receiving tcp windowupdate.

While issuing a POST login request to the website
http://portal.greatsouthernwood.com it was noticed it would hang for several
minutes until finally a timeout occurred.
Topology of environment:

Client --> Squid --> FortiGate --> DSL

Upon pcap investigation we noticed the following series of events:

1. POST request from squid to FortiGate
2. FortiGate sends a TCP ZeroWindow to pause connection for webfilter
function(by design)
3. FortiGate immediately sends TCP Window Update to continue
4. Squid does not retransmit for 2 minutes. No ACK was seen by the initial POST
so Squid should have triggered a retransmit based on its' retransmit timeout,
which is surely not 2 minutes.

I have screenshots showing the interesting streams. (will upload if possible)

retransmit-broken.png -- when issue happens
retransmit-working.png -- when issue doesnt happen(expected behavior)

the 10.x address is the squid server...this is occurring in approximately 2000
environments running squid all on different providers, so it's definitely not
isolated to one device. Any assistance in figuring this out would be
appreciated.

It should be noted when we disable the webfilter on the FortiGate, there are no
more tcp zerowindows being sent, therefore the issue goes away...so it really
does appear to affect things due to that flag.

This is occurring with Squid only on Ubuntu(tried on other distros to recreate and haven't been able to), therefore I wonder if it's something with the OS itself.

OS: (Ubuntu 12.10)
Squid: 3.1.20