expected behavior of 802.1p mapping & schedulers

the killer is traffic patterns - if the traffic level is continuous, then for strict priority all other Qs would get starved and only high priority would get thru

note that the Q sizes on a LAN switch would fill in a fraction of 1 sec.

"reordering" doesnt really mean much when you are comparing traffic flowing through different ports, since they were in different "sets" to start with.

802.1 link aggregation basically redefines "order" to be something that is only relevant in a flow with a common source and destination.

although this is specific to load balancing, it is a good way to think about QoS flows as well - ie "reordering" only matters when it affects packets that might arrive in a different order at a service on a device expecting an ordered flow. Reordering between different flows is not an general issue as long as the traffic arrives in a timely way since the flows are dealt with separately.

strict priority typically only affects 1 Q. Most switches also dont have 8 Qs (at least 2 to be useful, 4 is common).

Also most manufacturers allow limits on bandwidth per priority

so as in most QoS stuff - it depends.

Parenthetical note: 802.1p doesn't exist anymore. The priority levels had already been included in the VLAN tag of 802.1q, so now

802.1Q-2005 is used for prioritized frames and for VLANs. The 802.1Q tag can be coded to use only priority levels, and no separate VLANs, if you want.

As Stephen indicated, without stating this explicitly, 802.1Q doesn't mandate anything very specific about implementation of priority levels. Clauses 6.3.9, 8.6 and Appendix G say about all there is to say. In general, to be backward compatible, priority 0 is assigned to the typical "best effort" traffic, and priority 1 is actually even lower priority than 0, "background." But the highest priority is 7, "network control."

Aside from the reversal of what is expected to be high priority and low priority (0 is low, 4 is higher priority than 0), I think that the behavior can be as you show, or something different, depending on traffic volume and mix, and depending on the manufacturer of the switch. For instance, you might begin discarding lower priority frames altogether, when queues fill up.

Priority schemes fall apart if there's too much high priority traffic, for instance. And they can become awfully complicated if you try to support 8 levels of service class. If you have a small enough volume of high priority traffic, a decent approach is to only allow so many high priority frames in front of a lower priority frame, so you don't freeze out the low priority traffic.

I think by "reordering," you meant that the order of frames entering the switch at different ports would become different from the ordering of frames exiting the switch? For instance, if frame A enters p1 before frame B enters p2, it's entirely possible that frame B will exit the switch before frame A, if frame B has higher priority. But for any given "flow," source port to destination port, those frames should not become reordered.

Bert