TCP SACK delays on Solaris 8

Question

I hope this is the right place to post this; I couldn't see anywhere more relevant.
I'm noticing delays when accessing a server (Solaris 8 with patch 109472-07) which is behind a hub that suffers from an above-average loss of packets. The delay can be of the order of 4-5 seconds and seems to occur when the client (IE/Netscape browser on unix/nt/linux communicationg in http 1.1) responds with a SACK message to indicate that packets were lost.
It seems that TCP couldn't work out the right packets to send since the server then (after the delay) began sending data from the beginning of the window that was last acknowledged by the client.
The server application was a java program using the default socket parameters.
Oddly, a C++ application on the server doesn't seem to exhibit the same behaviour (which uses http 1.0 protocol).
Has anyone had similar experiences?

Answer 1

I've looked into this further with the help of a document that describes sack (and other recovery mechanisms) quite nicely:
http://citeseer.nj.nec.com/fall96simulationbased.html
Also, there is further discussion of congestion in:
http://citeseer.nj.nec.com/context/586582/0
It appears that the network I'm using has too many packet losses due to a wrongly configured network connection in which a half-duplex link is used by a router as though its a full-duplex link.
When sending out a block of data as a rapid succession of packets from the server, there is a threshold of data (about 6 packets of 1460 bytes) above which the outgoing packets start colliding with the returning acknowledgement. Sack hepls initially, but as the data size increases further, sack cannot cope anymore and transmission stops for tcp_rexmit_interval_initial, after which transmission restarts using a slow start from the beginning of the transmit window.