expected behavior of 802.1p mapping & schedulers

[Mark]

Hello,

I'm trying to understand the expected behavior of a L2 switch with enabled
QoS and 802.1p mapping, i.e. cos 0 is mapped to queue 0, cos 1 to queue 1
and so on.

Consider example: 1G ports, pump traffic from port1 to port3 and from port2
to port3 at a maximum rate, as a result port3 is unable to sustain it; in
such case enabling priority mapping will prioritize one type of traffic over
another, does this mean that I will see high priority frames leaving the
egress port first, and then only low-priority packets, i.e. I will observe
packets re-ordering at the egress side?

To backup my reasoning, here is the example -- L2 switch with 4 queues (0
has the highest priority), maps COS values in such way:

p1 has cos7 -> q3
p2 has cos5 -> q2
p3 has cos3 -> q1
p4 has cos0 -> q0

p1,p2,p3,p4 --->[L2 switch with 802.1p mapping] -----> p4,p3,p2,p1

I believe this is correct when strict priority queuing is enabled. Is my
understanding of the priority mapping and switch's behavior correct?

Thanks in advance for comments !

Mark

[Stephen]

On Wed, 21 Sep 2011 23:09:24 -0400, "Mark"
<mark_cruz...@hotmail.com> wrote:

>Hello,
>
>I'm trying to understand the expected behavior of a L2 switch with enabled
>QoS and 802.1p mapping, i.e. cos 0 is mapped to queue 0, cos 1 to queue 1
>and so on.
>
>Consider example: 1G ports, pump traffic from port1 to port3 and from port2
>to port3 at a maximum rate, as a result port3 is unable to sustain it; in
>such case enabling priority mapping will prioritize one type of traffic over
>another, does this mean that I will see high priority frames leaving the
>egress port first, and then only low-priority packets, i.e. I will observe
>packets re-ordering at the egress side?

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.

>
>To backup my reasoning, here is the example -- L2 switch with 4 queues (0
>has the highest priority), maps COS values in such way:
>
>p1 has cos7 -> q3
>p2 has cos5 -> q2
>p3 has cos3 -> q1
>p4 has cos0 -> q0
>
>p1,p2,p3,p4 --->[L2 switch with 802.1p mapping] -----> p4,p3,p2,p1
>
>I believe this is correct when strict priority queuing is enabled. Is my
>understanding of the priority mapping and switch's behavior correct?
>

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.

>Thanks in advance for comments !
>
>Mark
>

--
Regards

stephe...@xyzworld.com - replace xyz with ntl

[Albert Manfredi]

On Sep 21, 11:09 pm, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Hello,
>
> I'm trying to understand the expected behavior of a L2 switch with enabled
> QoS and 802.1p mapping, i.e. cos 0 is mapped to queue 0, cos 1 to queue 1
> and so on.

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.

> Consider example:  1G ports, pump traffic from port1 to port3 and from port2
> to port3 at a maximum rate, as a result port3 is unable to sustain it; in
> such case enabling priority mapping will prioritize one type of traffic over
> another, does this mean that I will see high priority frames leaving the
> egress port first, and then only low-priority packets, i.e. I will observe
> packets re-ordering at the egress side?

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."

> To backup my reasoning, here is the example --  L2 switch with 4 queues (0
> has the highest priority), maps COS values in such way:
>
> p1 has cos7  -> q3
> p2 has cos5  -> q2
> p3 has cos3  -> q1
> p4 has cos0  -> q0
>
> p1,p2,p3,p4 --->[L2 switch with 802.1p mapping] -----> p4,p3,p2,p1
>
> I believe this is correct when strict priority queuing is enabled. Is my
> understanding of the priority mapping and switch's behavior correct?

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