The reasons why CUBIC (possibly LP might have same problems) behaves wrong are two-folds.
 
First, CUBIC window growth function was incorrectly since we published. During some optimization of the code, the window growth function had been changed since we published a correct working code. The latest kernel already applied this patch. I attached this patch "tcp_cubic.patch".
Second, tp->rx_opt.rcv_tsecr variable is not correctly adjusted in tcp-linux.cc. This value is currently used by only two protocols (CUBIC and TCP-LP). I attached this patch "tcp-linux.cc.patch" 
 
As you verified other protocols, I tested bic, reno, cubic, and htcp protocols. The result was quite similar with dummynet testbed. 
Finally I posted the result of CUBIC protocols at http://netsrv.csc.ncsu.edu/ns/ns2linux/
 
For information, 200Mbps bottleneck, 320ms RTT, 100%BDP Queue, 2 CUBIC flows result are here at http://netsrv.csc.ncsu.edu/ns/ns2linux/600-200-160-0-1-cubic-2-0-0-0-1/hsflow_cwnd.png
400Mbps, 160ms RTT, 100%BDP Queue, 4 CUBIC flows and 4 TCP-SACK flows (without window limit) result is here http://netsrv.csc.ncsu.edu/ns/ns2linux/600-400-80-0-1-cubic-4-0-4-0-1/hsflow_cwnd.png