In example 1, are these statements true?
-10% of 300Mbps will always be reserved for udp 1200, even during times of congestion
No, but it works differently then you're thinking because you're using the priority statement.
-If no udp 1200 is being used, the 300Mbps can be fully used by any other service
Yes.
-Does the "fair-queue" shape or police the traffic? Or is it literally fifo?
Neither and no. (FQ defines a set of queues that flows use, they are dequeued round-robin, unless WFQ is being used.)
-Can traffic go beyond 300Mbps if the link allows it to?
Yes.
!In example 2, are these statements true?
-30Mbps will always be reserved for udp 1200, even during times of congestion
No, and again, a priority bandwidth works differently.
-If no udp 1200 is being used, the 300Mbps can be fully used by any other service
Yes.
-Any bandwidth that goes beyond 300Mbps will be shaped
Yes.
The priority statement uses LLQ, which uses one FIFO queue for any/all classes so defined, and that one queue is dequeued before any other traffic. Each class that's defined with priority also has an implicit policer that will drop traffic above the configured rate, if that traffic is queued.
For what you explained, you could do something like set your special traffic class to whatever bandwidth you know it should never exceed, your 30 Mbps (or 10% of your 300). This would insure this traffic always goes first when there's congestion. Do note, often traffic rates are averages, and short term intervals might go much higher, but a policer usually measures on a short term. So, what happens, policers will often "unexpectively" drop traffic.
As an alternative, you could use an ordinary bandwidth statement, and configure it to provide the average needed bandwidth. Short term bandwidth bursts would be queued rather than policed.
Additionally, LLQ should be reserved for traffic that really needs it, such as VoIP bearer traffic.
Also from what you explained, if you have a 300 Mbps CIR, with a gig hand-off, you'll want to shape like you do in your second example. Otherwise, QoS won't engage until the physical interface congests.
Lastly, when using a shaper, most appear to only measure L3 throughput, but CIR are generally set as a L2 throughput, so I've found setting a shaper at about 15% slower than CIR allows for average L2 overhead.
