Need more details why this added payload size would make the processing faster.

Please provide examples of other layer 2 protocols where this payload size is present and an example that shows how using this field improves processing time.

Following a more detailed description of the situation:

In the event of an OPC-UA UADP frame containing at least two DataSetMessages:
A packet processor can read the frame in an ordered sequence, each information needed to know the size of each fields of the frame is present in the frame before evaluating the said field; for example if the messageNonce is used in the SecurityHeader, the NonceLength is present giving us the information needed to know the size of the field, in the payload, the fields “Sizes” give us the size of every DataSetMessages.
The packet processor doesn’t need to determine the size of the any of the field, those information are all contained in the frame.

In the event of an OPC-UA UADP frame containing only one DataSetMessage:
The field “Sizes” is omitted in the Payload.
As a consequence the packet processor is forced to use the frame length available in the descriptor and subtracts the fields one after the other while going through the frame until it reach the beginning of the payload, then it needs to also remove the security footer if any to know the size of the DataSetMessage.
The packet processor needs to compute the size of the DataSetMessage instead of just reading it.

Alexander and/or Thomas,

Please comment or add to the agenda for the next TSN call.

Any update on this topic/issue?

If UADP was designed for 'Streaming' I would understand the concerns. But since UADP is for Message-Oriented protocols I don't see a problem here.
The receiver knows the message size from the IP/UDP headers (or from MQTT Packet Length, or AMQP size field).
Transmitting the length for a UADP message would be redundant.
I think a good packet processor should always substract the fields one after the other while going through the frame in order to detect malformed frames.

The point was not the IP/UDP or MQTT/AMQP option of OPC UA. This is no problem, as you have described.
The question is on the RAW ethernet option. There is no IP/UDP header or similar layer providing the message size.
The UADP packet is directly embedded in the RAW ethenet frame.
Problem is both, the UADP header as well as the ether frame, don't provide any message size information.

That woud be also a question of TSN compatibility.
If you want to use a standard cut-through switch, then there is no problem since the switch starts to forward the message and completes when the whole message has been transmitted.
With TSN and 802.1Qbv the switch must be certain that a message is not transmitted beyond the end of the Qbv window. The current raw Ethernet UADP proposal means that the switch cannot know the length of the message until the message has been parsed, or the Ethernet frame has been completed.

The statement that the ether frame does not provide any message size information is not fully true. The message size information is not sent as value on the wire, but it is implicitly known when the frame was received completely. So for the Subscriber of a UADP message (also on RAW ethernet) I still do not see a need for an extra field since it will not start analyzing the frame before it was received completely (inclusive checksum).

I'm not considering that Qbv-switches would analyze the payload of the data (IP, ARP, ICMP, MPLS, .....) to make any transmission decision based on the 'predicted' packet length.
I say predicted because it is still not said that an ether frame does not carry any dummy data after the actual payload. The switch can never detect this unless the frame is completed.

So I think the combination Qbv + cutthrough should be handled without knowledge about the frame length, and I see two options:

• Continue sending, even if the window closes
• Break the frame when the window closes and resend next time (quite ugly)

This is more an IEEE topic than OPCUA I feel.

I agree with Thomas last reply. The length of an Ethernet Frame is typically delivered by the service layer (raw socket api) separatly from the frame data.
Furthermore: In a clean layering architecture a packet processor anyway has to wait for the crc evaluation of the layer 2 frame before it can take the payload as valid data.
Maybe I missed the point of your issue. We can discuss this on Monday in the UA TSN subgroup call.

I reviewed this thread: I guess that we are discussing at least three topics we should clearly separate:

1) Is a size information of UADP Data only contained if there are more than 1 DataSets in the NetworkMessage?
I think this is related to the supported UADP Message Layouts. Thomas is the expert here.

2) Does a size Information in the Layer2 Header make sense for
a) UADP Packet Processing in end stations.
b) Frame forwarding in context of a switch regarding cut through and Qbr (actually a IEEE topic)

Alexander is right, we can split this up into different aspects:

ad (1)
In UADP it is an option to transfer size information for the embedded DataSetMessages, but not for the complete NetworkMessage. The header 'before' the size-fields can be of dynamic length, so the size-fields are not the solution Michael is asking for.

ad(2)
I'm still confused why we would call the UADP Layer an 'Layer2 Header'.
MAC is Layer2.
UADP is higher than Layer2 (I don't want to discuss when and whether UADP is at Layer3 or higher, or even a combination of several layers, but not Layer 2).

ad (2a)
As mentioned before I do not think that packet processing on the Subscriber would need additional information about the size of the NetworkMessage because it can already be evaluated by 2 different ways ... by checking the size of the ethernet frame, and by parsing the message. When the parser detects more bytes than the ethernet frame contains, the NetworkMessageWriter did obviously not read Part 14.

ad (2b)
cut-through is the only possible reason I can imagine which could make use of such an size information. The cut-through would have to detect that this is an UADP-Frame, wait until the size information is received, and then only it can decide whether it would transmit the frame now, or in the next Qbv-slot.
In case of IP-Frames this mechanism would have to wait until the field TotalLength of the IP-Header is received before it can decide whether it should cut-through the frame.
In case of MPLS the mechanism would have to jump over the MPLS header and analyse the following Layer3-Header (IP, UADP, ...) to know where the size is.
At the end the cut-through mechanism would behave differently depending on the type of Layer3 protocol.
And what would the switch do when an unknown ethertype comes in, and it cannot determine where to find the size information?
As I mentioned already ... this is an IEEE discussion, and I guess they don't care about size-information in Layer3-Headers when discussing cut-through.

We discussed the issue with Michael in the TSN WG Call (12th of August) and agreed on these recommendations:

• CRC of Layer2 Frame has to be checked anyway before reading any payload or NetworkMessage information.
• We recommend to take the fixed header layout profile to guarantee fixed offsets of the DataSetMessages to speed up processing.
• Issue can be closed / rejected.

Agreed to no-fix in UA TSN meeting today.