This paper looks at when TCP is "not" TCP by analysis of five years of data on a Japanese data set. That is to say, when TCP throughput is limited by mechanisms other than traditional TCP rate control (loss or delay in the network feedback causing a reduction in window size).
Other mechanisms are important:
1) Application limiting where the sender "dribbles" out data more slowly, for example in the way that you tube does, to reduce their bandwidth.
2) Window size limitations -- where hosts have an OS built in limitation on how large the TCP window can be.
3) Middle box/receiver window tweaking -- where the receiver or (more likely) a middle box tweaks the advertised window size to reduce throughput.
It is found that in the traces studied these three mechanisms account for more than half the packets. The traces include data from well known sites such as YouTube and it seems likely that the findings are more general than just applicability to this particular trace set.
In general this paper finds that TCP in the wild is not behaving in the way it is traditionally taught... by a variety of mechanisms, TCP is not "filling a pipe" and "controlled by loss"... other mechanisms are at play beyond traditional TCP congestion control.