There should also be a way to track the "ack backlog". By that I mean, if you can see that the packets being acked were sent 10 seconds ago and they are consistently so, you should then be able to determine that you are likely (10 seconds - real RTT - processing delay) deep in buffers somewhere. If you back off on the number of packets in flight and that ack backlog doesn't seem to change much, then the congestion is probably not related to your specific flow. It is likely due to aggregate congestion somewhere in the path. Could be a congested peering point, pop, busy distant end, whatever. But if the backing off DOES significantly reduce the ack backlog (acks are now arriving for packets sent only 5 seconds ago rather than 10) then you have a notion that the flow is a significant contributor to the total backlog. Exactly what one would do with that information is the question, I guess.
Is the backlog consistent across all flows or just one? If it is consistent across all flows then the source of buffering is very close to you. If it is wildly different, it is likely somewhere in the path of that particular flow. And looking at the document linked concerning CDG, I see they take that into account. If I back off but the RTT doesn't decrease, then my flow is not a significant contributor to the delay. The problem with the algorithm to my mind is that finding the size of "the queue" for any particular flow is practically impossible because each flow will have its own specific amount of buffering along the path and if you get into things like asymmetric routing where the reply path might not be the same as the send path (multihomed transit provider or end node sending reply traffic over different peer than the traffic in the other direction is arriving on) or (worse) where ECMP is being done across peers on a packet by packed and not flow-based basis. At that point it is impossible to really profile the path.
So if I were designing such an algorithm, I would try to determine: Is the delay consistent across all flows? Is the delay consistent even within a single flow? When I reduce my rate, does the backlog drop? Exactly what I would do with that information would require more thought.