1931   Priority tag assumption for Class P1 vs P2

Created: 13 Jun 2024

Status: Triage

Part: Part 5 (2022)


Page: 76


Paragraph: -


Part 5 Ed2.1, Cl
(Aside: please add “Table Number” captions)

The P1 and P2 Performance class seems to need further clarification of the relativity of the Priority Tag value for P1 and P2.
This impacts the context for which testing system conformance would apply.

Consider one Publisher with two different GOOSE configs – one as P1 class (required =3 ms latency), and one as P2 (required =10 ms latency).
Obviously all messages travel on each network segment at the same speed and sequentially in the order they were issued by the last egress port.
At the next switch/router, the order of sending may change and indeed other messages may be prioritised and hence one message can “jump the queue” to reduce its overall latency.

We also know that LAN Switches have default priority assignments which sometimes get added to the egress frame in absence of the ingress frame tag.
And we know the switches have settings of how many higher priority they pass before the next lower priority is handled.

In other words, the publishing port to subscribing port latency difference over the LAN for P1 and P2 is only affected by the Priority tag handling through the intermediate switches.

Scenario 1: If a Publisher has a simultaneous trigger for both a P1 and a P2 GOOSE, this class difference should mean the Publisher decides to issue the P1 message first.

Scenario 2: Somewhere there is a Subscriber for both a P1 and a P2 message from the same Publisher.
Consider a trigger for the P2 message so it is sent immediately .. and a very short time later a different trigger for the P1.
P2 is travelling first followed by the P1 message.
The only way for the P1 message to have a lower latency than the P2 message is by use of Priority Tag to “jump the queue” through the LAN switches, i.e. delaying the P2 to be behind the P1 on the next LAN segment.

Hence P1 and P2 have some implicit relative Priority Tag allocation i.e. P2 has a lower Priority Tag than P1 to ensure P1 gets the preferential passage.

Therefore, the P1 latency perhaps should be clarified as to what Priority tag is being assigned by the Publisher
.. and what that Publishers P2 Priority tag should be.

Questions for the WG are:
Does the P1 assume at least Priority 4 as per “recommended” values in Part 90-3?
P2 then needs to be defined based on a value of being less than the P1 setting .. but by how much?


Add text about using Priority Tag to aid in relative latency compliance.

Add an extra column "Priority Tagging"
P1 as required
P2 at least one Priority lower than P1

Discussion Created Status
Indeed port speeds make a big difference to latency reduction.

But, continuing the rough analogy, there isn't just one ambulance or tow truck in the network, there are cars, busses, bicycles, semi trailers as well as 3-trailer road-train .. traffic of all sorts!

MMS file transfers is a good example .. especially with automatic asset management systems requesting COMTRADE and COMFEDE from all devices involved in an event .. then suddenly another P1 GOOSE has to barge its way through.
The existence of the Priority tag in the overall message is inevitable - that is how Ethernet switches work.

So does the System Integrator want the Priority determined by whatever the default Port Priority is of the first switch the message arrives at .. and hence the same for all messages from that device

... or perhaps there is reason that some messages from that device can be demoted to a lower priority to help the entire system "play well" .. also noting the Systems Integrator is not necessarily in control of all traffic on the network and not all as GOOSE/SV/MMS.

At the end of the day, the latency can only be verified as part of an operating system .. and even then only under maximum traffic conditions. But the engineering of the system has to be in anticipation of the worst case and that is what Priority tag is helping with.

Al I am suggesting is we add some sort of qualifier column to the Performance classes such as

P1 seems to be recommended as to be at least 4 (now THAT is something never understood why "so low")
P2 is recommended to be P1 class priority minus 1
P3 is recommended to be P2 class priority minus 1
13 Jun 24 Triage
I agree with the comment timestamped at 11:33.
Critical networks (such as power systems) should be over-provisioned to absolutely minimize latency effects. But let us look into some actual latencies assuming one big low-priority MMS Ethernet frame arrives just before a "fast" GOOSE of length 150 octets. Further assume 100 Mbit transmit speeds.
Under ideal conditions, the fast GOOSE takes 1.5 microseconds to traverse each (store-and-forward) switch whereas the "big frame" requires 15 microseconds to traverse each switch. Given the 3000-microsecond message delivery requirement, the latency addition based upon "waiting for low priority traffic before high priority traffic" is 0.5% of the latency budget.

I claim this to be insignificant even in the most bizarre scenario I can imagine. The "tow-truck" will result in the "emergency vehicle" arriving a few milliseconds late to hospital. If latency reduction is needed, frame prioritization is not the place to begin.
13 Jun 24 Triage
Interesting view Fred ...
Tagging is an inherent part of Ethernet frames.
If a switch receives untagged frames from a publishing device, it adds them anyway according to Port defaults. Then on egress from the switch it may or may not include the tags on egress depending other port settings and what it is communicating to.
So Tags can be confusing if "left to their own nuances" .. and that is why we prefer to set them at source to keep them under control!

VLAN Tag is used extensively for traffic management and is the only mechanism for MMS. Some (mis)use it for GOOSE/SV traffic management instead of Multicast Filtering
So once you create VLAN tag - by first switch ingress port default or at publisher - you automatically get the Priority tag field as well.
So the EtherNet frame cannot deprecate the Priority Tag field.

As my scenarios indicate, given the Standard defines three classes of GOOSE as fast, medium and slow overall latency classes, Priority is the only distinguishing mechanism

So why have three classes .. consider an IED GOOSEing a Prot operation vs something less time critical .. e.g. an "analog-GOOSE" ... we need to let the "emergency vehicles" through the toll gate before the "tow trucks"

How much difference in latency Priority may make in different size networks and traffic .. a thesis topic for some student??
.. but it does make "a" difference
.. and I don't want to be the person explaining why I left everything to their own nuances and "fingers crossed" it works "well enough"
Equally, setting everything to Priority 7 doesn't help.

SO at least let us help guide engineering decisions and performance requirements with what Priority should be used in different circumstances
13 Jun 24 Triage
We did no good with introducing the tagging of GOOSE and SV packets at the publisher. The "priority only" modes in switches never worked as perceived and we got drawn into all the VLAN issues by this.
The actual benefits from the priority tagging/queuing are underwhelming as there are other effects that diminish its effect. With higher link speeds, the delays are insignificant anyway.
Instead of putting efforts into the related definitions, we should consider deprecating the tagging.
This would simplify the matter without impacting the performance.
13 Jun 24 Triage


Privacy | Contact | Disclaimer

Tissue DB v.