"LLQ class packets should be packets which are identified as priority packets speaking about that we're not congested . . ."
No. LLQ class packets are those that match the class attributes. Congestion isn't relevant.
". . . LLQ queued packets should be prioritized packets in the output queue during times of congestion."
LLQ queued packets might not be prioritized (consider if all your traffic is LLQ class), but, agreed, they will be queued, during times of congestion, although much depends on what you understand "congestion" to mean.
I consider "congestion" anytime a packet arrives at an egress interface and it cannot be immediately transmitted, i.e. it needs to be queued. This, BTW, doesn't correspond with typical measures of "congested" interfaces/link, i.e. some percentage of usage above zero to 100%. For example, you might have very bad congestion with an interface/link showing even 1% utilization or conversely no congestion, at all, while interface/link utilization showing at 100%.
Example of the forging. Gig ingress to FE egress, sends just 10 packets, back-to-back, in some multi-minutes time frame. When the first packet arrives, it's immediately transmitted, but the next 9 packets, in the series, may (why "may", because packets can be variable sized) need to be queued. If all are queued, then later transmitted, your interface/link usage percentage might be very low (again assuming only 10 packets are sent during some multi-minute time interval). However, if the egress queue could only contain 1 packets, 8 of the 10 packets would be dropped. Interface/link usage, though, would show an even lower utilization percentage!
Or, consider, FE ingress, FE egress, and ingress is providing back-to-back packets, continuously. Interface/link utilization would show at 100%, but there would be zero queuing at egress interface. (Also, zero drops!)
So, "congestion", I believe, strictly depends on whether there's a need to queue packets.
To your question. Packets that match the LLQ class attributes, are always LLQ class packets.
LLQ class packets, will only need to be queued, if they cannot be immediately transmitted.
If LLQ class packets are queued, they will be dequeued ahead of any other class queues.
As LLQ class packets are being dequeued, they are checked for their transmission rate. If in excess if the implicit policer value, LLQ packets will be dropped such that the overall transmission rate is at or below the implicit policer value.
If no traffic is being queued, or just LLQ class traffic isn't being queued, it (LLQ) can consume all available bandwidth.
BTW, if you define an explicit policer, for the LLQ class, it will police LLQ class traffic regardless of whether it's being queued or not.
Does the above help?
