For inbound, although there are many Internet addresses, you can still identify the VLANs by internal source addresses. In other words, for outbound you match to source address, for inbound you match to destination addresses.
Yes, you've got it. When you try to manage traffic downstream of the bottleneck with a policer, the bottleneck can still be congested with traffic. If the inbound traffic is TCP, it should slow if it sees drops caused by the policer, so a downstream policier can have some impact regulating inbound upstream traffic. Problem is, TCP bursts first, sees the drops, then slows. In my experience, you need to police much slower than you really want to keep the bursts from choking the link which tends to drop the average inbound rate of that traffic. (It can be a useful technique, though, to target bulk background data transfers.) Some traffic, like UDP applications, may not slow their rate at all when they see policer drops, but those drops will often adversely impact the application.
Your're also correct, 3560 can do inbound stuff, but it can do some port based outbound stuff too, including, I believe, bandwidth idleing of a port. For the inbound stuff, you often can control both direction by doing inbound (or outbound) on both "sides" of the switch, i.e. inbound on both LAN facing and WAN facing ports.
Your best hope on something like a 3560 would be to configure the output port bandwidth usage to match the upstream available bandwidth and then separate traffic into one of the four queues. You would detmine the bandwidth allowance for each of the four queues. (No fancy CBWFQ for output supported on that platform.)
For inbound, if you find there's one type of TCP traffic that tends to use most of the bandwidth of the inbound link, you can police that down to a low value of the link's bandwidth, perhaps under 10% or more. (TCP should still manage to forward the traffic.)
Beyond that, you could obtain a small WAN router for between the 3560 and the WAN. This would allow you to implement better QoS outbound, but it wouldn't really help much with inbound, although another technique is to shape outbound TCP ACKs, but that's very trickly to get to work well too.
Lastly, there are 3rd party traffic appliances (e.g. Packeteer) that can really help in this situation since they often muck around with not only per flow shaping but can sometimes adjust certain TCP packet fields like what a receiving TCP host's receive window size is.
PS:
Yes, guess I do pop up alot on CBWFQ (or QoS in general). Perhaps a subspecially of mine is obtaining optimal performance with computer systems or the most "bang for the buck". Cisco's QoS features, such as CBWFQ, are often very useful, or even critical, in getting the best performance and/or to accomplish your business performance goals at minimal cost.
