I actually think I figured out the problem (or a portion of it) and found a suitable workaround.
In the course of investigating another issue, I stumbled across a change which also addressed this. I was seeing worse network performance than I expected when there was ‘heavy upload’ activity on the link (for such a small link this means a few active http file uploads was more than sufficient). Such activity was very strongly impacting the achieved network receive throughput – much more so than I would’ve expected over a full-duplex link. The issue ended up being the ‘upload bandwidth’ parameter on the peplink WAN – this parameter was configured to match the upload capacity of the tx channel of our link – 96 kbps. Apparently this parameter has the affect of setting a queue or buffer size or having the peplink enforce some traffic shaping/policing to that configured capacity – I think I will do some experiments to determine exactly what the behavior of that parameter is but that will have to be at a later time … Whatever the traffic queuing behavior on the peplink is – its not a good choice for our small link’s outbound traffic. With the outbound bottleneck at the peplink, it was very easy for active flows to have an over-stated advantage over less active flows and essentially starve tcp acks and new tcp connections.
I instead configured the ‘upload bandwidth’ on the link to be significantly greater than the actual channel capacity – this has the affect of moving the outbound traffic bottleneck forward to the edge gateway device. The edge gateway device for this link is a cisco 2811 router – by default a cisco router uses flow based weighted fair queuing as the queueing mechanism for all links with less than 2Mbps bandwidth. This queueing algorithm has the effect of causing flows to quickly converge on a rough split of the channel capacity while avoiding the ability for an active flow to starve out new connections and less active flows (ack responses and new tcp connections). Its the default for links with less than 2Mbps capacity because its behavior is well-suited to very low bandwidth links.
This change solved the ‘upload activity overly slows network’ issue and also had the effect of solving the issue of ever-rising speedfusion latency. It seems that speedfusion is now able to find the correct packet flow rate and continue forward progress in a more appropriate manner … The latency value graphed in the speedfusion performance ui still rises when there is an active speedfusion flow – but it stops around 5-6000ms and stays there while the flow is active rather than rising towards infinity as it did before …
Let me know if you still want me to open a ticket.