Some elaboration on a use case that would benefit from this:

As a machine builder, I want to limit the maximum packet size sent on the Ethernet interface:

• Controller has single Ethernet interface
• Application traffic includes motion as well as non-time-critical traffic
• TSN is not being used
• Motion traffic latency must account for 1 large packet in the process of transmission.
• If controller application allows 10 connections to be aggregated into a 1500 byte packet, it affects motion latency
• Therefore it is useful to limit the max packet size that will be transmitted
• Ideally, this would be on a per-interface basis

Added more settings to PubSubCapabilitiesType
MaxDataSetWritersPerGroup
MaxNetworkMessageSizeEthernet
MaxNetworkMessageSizeUDP

The MaxDataSetWritersPerGroup Variable defines the maximum number of DataSetWriters that can be configured in one WriterGroup. A value of 0 indicates that the OPC UA Application forces no limit on the number of DataSetWriters in one WriterGroup.

The MaxNetworkMessageSizeEthernet Variable defines the maximum number of bytes that can be configured as MaxNetworkMessageSize for NetworkMessages sent or received through OPC UA Ethernet transport protocol mapping. A value of 0 indicates that the OPC UA Application forces no limit on the maximum size.

The MaxNetworkMessageSizeUDP Variable defines the maximum number of bytes that can be configured as MaxNetworkMessageSize for NetworkMessages sent or received through OPC UA UDP transport protocol mapping. A value of 0 indicates that the OPC UA Application forces no limit on the maximum size.

Added in
OPC 10000-14 - UA Specification Part 14 - PubSub 1.05.02 Draft2.docx

If there are network interface specific limits, they should be added to the network interface definition in Part 22

Need to add capability to the network for the use case Brian describes.

Configuration of the application-level network message sizes is configured using MaxNetworkMessageSize in Part 14.

Configuration of the network interface is the responsibility of network management. The max frame length is configured over such mechanisms (e.g., NETCONF). The OPC UA stack reads this information and should display it in a read-only variable such as MaxFrameLength (taken from ieee802-ethernet-interface.yang) instead of the MaxNetworkMessageSizeEthernet and MaxNetworkMessageSizeUDP variables that were added to Part 14.

MaxNetworkMessageSizeEthernet and MaxNetworkMessageSizeUDP Variables should be removed from Part 14 (there is no need for separate values for Ethernet and UDP as that can be calculated).

One new max frame length (MaxFrameLength) will be added to Part 22.

If an application needs another frame length on the network, it must use network configuration means (e.g., NETCONF) to set the max frame length accordingly. The new max frame length is shown in the MaxFrameLength shortly after setting the max frame length successfully.

The Part 14 1.05.02 RC does not have MaxNetworkMessageSizeEthernet and MaxNetworkMessageSizeUDP anymore.
Brian had related network setting specific requirements but my related additions were rejected by the UA WG and the Mantis Issue was assigned to Part 22 since such limits are more related to the network interfaces.

Part 14 has only optional MaxNetworkMessageSizeDatagram and MaxNetworkMessageSizeBroker to allow the application to set a max. This was a different requirement to be able to set application specific limits.

But the requirement that was introduced by Brian (see text of issue 0007737) should be discussed and solved potentially by BNM and therefore the issues was moved from Part 14 to Part 22

The use case I was concerned with was a configured controller (with a user applicatoin) being able to advertise a limit on what size PubSub message can be created. E.g., to prevent another Connection Manager from creating a UAFX connection with a very large DataSet, or trying to aggregate a number of connections thereby creating a large packet.

I wasn't thinking of solving this at a network-level, which would bring in other complications, such as: are all applications on the device intended to adhere to this limit? What if they produce a frame that is larger? Is it just dropped? Similarly for PubSub, if such as max frame size were set, then the entity configuring PubSub would need to know about this, and should receive an error message if if tried to create a publication that exceeded the limit (this should be a design time or at worst connection establishment time action to detect the error)

Applications (e.g., Motion) that require strict timing should not be held off by lower priority traffic. QoS can be used to prioritize traffic, but if a long packet of lower priority starts on the wire, it can hold up higher priority traffic. We were asking for a mechanism to limit the size of packets so that we could predict how long this delay could be. The problem is that anything we define in OPC UA would not protect us against other apps (e.g., web traffic). If we did apply a system-wide solution such as setting MaxFrameLength using NETCONF, then we would end up with other issues (e.g., web traffic being dropped with no indication as to why).

We now believe that Part 14 provides us with the ability to control the only thing we can control (MaxNetworkMessageSizeDatagram). No further action is needed.

Agreed to no-change-required in Web meeting.