The drops you are observing are due to shaping drops, i.e. nothing to do with your ISP possibly dropping.
Likely "bursts" to your tunnel's shaper are overrunning the 5 Mbps shape rate, and as the shaper might only be using a 64 packet size queue, it's also likely your filling that and overflowing.
What might be done, if the router supports it, is increasing the shaper's queue size (64 packets is probably shallow for 5 Mbps). NB: for "ideal" queue depth, for TCP, I've found half the BDP (bandwidth delay product) seems about right. (For 5 Mbps, and "typical" WAN latency, you might try a queue size of 256.)
What also may, or may not, reduce overall drops is using FQ or WRED (the latter I generally only recommend for "expert" QoS engineers). "Busy" flows should be those FQ hits with drops, "protecting" your other flows - FQ also avoids the global tail drop issue.)
BTW, although the drops you're seeing have nothing to do with ISP possibly dropping, exceeding your ISP's CIR of 5 Mbps, often will cause provider drops (which I assume you're trying to avoid using a shaper). I suspect, some Cisco shapers don't account for L2 bandwidth overhead, but a provider likely does. If so, with such shapers, to avoid provider drops, shape about 15% slower than CIR. (NB: how do you know if provider is dropping, since you have tunnel, compare egress packet count, to other side's ingress packet count, for same time period.)
PS:
BTW adjust-mss is generally set to 40 less than IP MTU.
