IMHO there's actually not any minimum guarantee. It's just that 4/7 of the time a packet from the "high" queue is being serviced (or 4 out of 7), but the 3 other times other queues will be serviced even if there's a packet waiting in the "high" queue.
Compare it to a 3-lane highway. In times of contention (and only then) each lane allows a certain amount of cars to pass. Lane 1 (the "high" queue) allows 4 cars to pass at a time. Then in the next lane 2 cars can pass. Then 1 car from the last lane. This way lane 1 is emptied faster than the other lanes and the cars in lane 3 have to wait the longest. There's an additional lane for emergencies. Cars on it are always allowed to pass no matter what. That's our DSCP 46 queue and the only one actually having a guarantee. The other lanes only get a certain amount of cars per time unit (let's say minute) which is guaranteed *over time*, but then the lane closes and the other ones open.
So basically what you configure with Meraki would be a weighted queue and a fixed priority queue (which you can't change). There's no minimum guarantee, there's a minimum guarantee *of bandwidth* which is a different thing since bandwidth is measured over time, and a lot can happen in 1 second (imagine a 1 second drop of your voice or video call).
> There are two High rules, 1 normal and 4 three low rules. Then what's the percentage of my individual high rule gets?
AFAIK if you fill the queue with just one type of traffic (Citrix in this example) it will get 4/7, but if there's an equal amount of packets waiting for each "high" rule you get 4/28 per rule (4 / (4 rules *7) ).
There's one exception to this (and it makes total sense). When a DSCP EF (46) packet is in a queue, it will be sent immediately even if other packets in other queues are waiting or are up to be scheduled. This is usually voice RTP traffic. This is a guarantee.
In the real world this does not make a huge difference, only when you need real-time traffic to be guaranteed then it's actually important. I assume that's why Meraki (from firmware 14 onwards) implemented the non-configurable priority queue for DSCP EF traffic.
I would recommend to first try the default traffic shaping rules. If they don't work out for you then try to eliminate or shape high-bandwidth (bulk) traffic wich doesn't need to be real-time, like e-mail etc., but don't put anything potentially high-bandwidth in "high".
So QoS in Meraki is pretty basic and it has less knobs and configurable options than you would expect just by looking at the dashboard. But in this case less might actually be more and it fits the Meraki mantra of simplicity.