A (very) delayed response (but perhaps useful to other readers). . .
As already noted in Daniele's post, you cannot allocate, proportion or set up and down (or egress/ingress) bandwidth as you wish, they are separate "channels". Egress/ingress bandwidth is determined by the technology and bandwidth limits imposed by a service provider.
By default, Cisco networks devices generally use FIFO queuing. Which means if you have heavy bandwidth consuming flows, tend to grab chucks of bandwidth for a consecutive sequence of packets (good example, a large data transfer using TCP during "slow start"). These data chunks tend to cause highly variable reception times of sequential packets of other flows, often very detrimental to light bandwidth consuming flows such as VoIP.
A good way to visualize the forgoing, image going to the market to only purchase milk, bread and eggs. You then go to the the cashier, and check-out in under a minute. Next time you do this, however, right before you get to the cashier, another shopper, gets to the cashier first and has an overflowing basket of goods. In this latter situation, you're much delayed by the other shopper's check-out.
In the network world, the solution to avoid/mitigate the impact of heavy bandwidth consuming flows impacting others, is some form of AQM (active queue management); done as part of some QoS policy. I.e. we re-order the sequence of how multiple flows, whose packets have been queued, are de-queued and transmitted.
In the case of the heavy bandwidth consuming flow, which has a large bunch of packets queued before the packets from the few packets of a light bandwidth consuming flow arrive, as the latter are received we might transmit them before any other heavy bandwidth consuming flow's packet is next transmitted (i.e. give then priority) or perhaps we "interleave" (i.e. transmit one flow's packet then another flow's packet, and so on) different flows' packets (generally known as fair queuing [FQ]).
Such forgoing AQM might be done when the physical interface congests, but in cases where the physical port offers more bandwidth then we know is available further "downstream", we "shape" for the expected downstream bandwidth and thus are able to actively manage traffic prioritization based on expected available bandwidth.
AQM can be done very well (and is pretty well supported on Cisco routers) for egress, but ingress is very problematic.
Ideally, ingress is managed as egress on the "other" or "far" side of the link/connection. When this cannot be done, there are some techniques that can be used, but the most effective techniques often require a "special" traffic management appliance, i.e. Cisco routers don't offer much in this regard (possibly because both these techniques are a bit complex and, again, the assumption might be they are not needed if you control both ends' egress).
In this case, I would suggest starting with an egress policy that supplies FQ, and if egress's downstream policy is less than port bandwidth, "shape" for that bandwidth.
E.g.
If egress port is 10 Mbps, and your provider provides all 10 Mbps:
policy-map Sample
class class-default
fair-queue
interface X !egress port
service-policy output Sample
If egress port is 100 Mbps, but your provider provides 20 Mbps:
policy-map Sample
class class-default
shape average 20000000 !you may need to shape about 15% slower if shaper doesn't account for L2 overhead
service-policy SampleChild
policy-map SampleChild
class class-default
fair-queue
interface X !egress port
service-policy output Sample
Again, the best way to deal with ingress, is "other" or "far" side's device, egress. If that's not possible, providing a "good" or "effective" QoS policy for ingress is very difficult to impossible on a Cisco router,
