Paolo, great question about passive/active FTP. (Roger, in case you miss the point, if your policy only "sees" active FTP, you developer downloads could be bypassing your shaper/policer if they're using passive FTP. If you're using NBAR matching to FTP, it should "see" both. [There's also the issue of "seeing" secure-FTP, from your original post.])
Paolo, your comment about a practical test, is also great, since it's often the only way to truly find out the impact. Very simple to change from a policer to shaper using the same policy. One thing to keep in mind, even if you simulate this in the lab, it still might not indicate what will happen in Roger's production. One reason is what TCP stacks are your lab systems going to use vs. what Roger's clients and the Internet servers use?
With regard to your comment about whether a policer vs. a shaper will cause more total transmissions, another good point. It could go either way. The reason being, much depends whether TCP has reached steady state or whether it's still opening its send window. If the latter, a huge number of burst packets could be dropped as they all fall off the end of the queue. With the former, the more aggressive feedback loop may prevent such large bursts from being sent. Regardless, though, even if more total packets are sent because of retransmissions, as long as we meet the primary consideration of protecting other traffic, I think it's a better trade off than performing FTP most efficiently.
Your point about using a shaper with a small buffer, I agree with, because a shaper with a very small queue depth starts to behave very much like a policer. (Don't recall, can you define the buffer depth for a shaper within CBWFQ?)
Roger, yes, it's not unexpected how difficult FTP is to tame inbound (downstream) unlike the success you mention taming SMTP outbound. As noted above, insure all your FTP, secure-FTP traffic is seen by your policy. Also, because of bursting issues, you might try reducing the allowance for FTP even further.
One technique I haven't mentioned is shaping outbound FTP ACKs. It avoids many drops that are often caused by a policer or shaper because it "clocks" the transmission rate. It will not stop all bursting, and a very low ACK rate is needed in comparison to the inbound data rate. (I'm unsure whether you could go slow enough to be effective on a 2 Mbps link.)
As to 3rd party solutions, they might use the outbound ACK pacing just described, although much more precise based on actual flow rates. They also might "spoof" the receiver's receive buffer size, a great technique, but unavailable, as far as I know, on a Cisco router.
