Strange TCP behavior after packet loss - 1 packet at a time despite large window, 5 sec delay

[Shawn T Carroll <shawnthomascarroll () yahoo com>]

Looking for any TCP experts to help explain this!
We are troubleshooting a slowness issue involving traffic through a load balancer, and we have found a smoking gun 
where a 9k file is being transferred, hits some packet loss, but then after what looks like successful retransmission, 
see what appears to be the load balancer sending 1 packet at a time, after waiting about 5 sec each packet. The result 
is that it takes 35 sec to transfer a 9k file (7 packets * 5 sec).
In the attached capture, you see:1. normal TCP behavior, and the lb attempting to transfer the file to the client 
(frames 15-22)2. some packet loss; the client ACKS for frame 15, about 7 packets back3. a pattern of:    client ACKs 
for the lb to retransmit some data
    lb ACKs that request
    lb waits 5 sec
    lb transmits the requested data
      (this pattern in frames 28-41)

I am confused, because:    the window size is fine (66640)
    yet the load balancer is transmitting only one packet before waiting for an ACK
    the lb waits 5 sec (an eternity) and never speeds up upon subsequent quick ACKs from the client


Can anyone explain what is going on here?What are the possible mechanisms in modern TCP that *should*, after some 
packet loss, be reducing the # packets sent, and/or increasing the time between sent packets?Could one of these be 
going haywire?Anyone seen something like this?
The lb is a NetScaler.
Thanks! :-) Shawn

Attachment: LB nstrace1-6-stream8only.cap
Description:

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe