52.8.3 Disabling IP Fragmentation for Real-Time WAN Transport

For WAN communications, it is not a good idea to rely on IP fragmentation. IP fragmentation causes significant issues in UDP, where there is no integrated support for a path MTU (maximum transmission unit) discovery protocol as there is in TCP. These are some of the problems associated with IP fragmentation:

• To successfully reassemble a packet, all fragments must be delivered. If a fragment is lost, the whole packet will be lost.
• Before reassembly, a host must hold partial fragment datagrams in memory. This opens an opportunity for memory exhaustion attacks.
• Subsequent fragments lack the higher-layer header. The TCP or UDP header is only present in the first fragment, making it impossible for firewalls to filter fragment datagrams based on criteria like source or destination ports.

For more information on IP-level versus Connext-level fragmentation, see 34.3 Large Data Fragmentation.

This section describes how to disable IP fragmentation in Connext applications using the RTI Real-Time WAN Transport. Instead, Connext will be responsible for fragmentation, done at the RTPS level. The key changes involve:

• Setting the Real-Time WAN Transport MTU (<message_size_max>) to be smaller than the typical IP MTU of around 1500 bytes. The recommendation is to be even more conservative and set the transport MTU to 1400 bytes.
• Enabling DDS fragmentation for reliable Topics (user and built-in Topics) by configuring the 47.20 PUBLISH_MODE QosPolicy (DDS Extension).

For example:

<qos_profile name="DisableIPFragmentationWAN">

    <domain_participant_qos>

        <discovery_config>

            <publication_writer_publish_mode>

                <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>

            </publication_writer_publish_mode>

            <subscription_writer_publish_mode>

                <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>

            </subscription_writer_publish_mode>

            <secure_volatile_writer_publish_mode>

                <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>

            </secure_volatile_writer_publish_mode>

            <service_request_writer_publish_mode>

                <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>

            </service_request_writer_publish_mode>

        </discovery_config>

        <transport_builtin>

            <mask>UDPv4_WAN</mask>

            <udpv4_wan>

                <message_size_max>1400</message_size_max>

            </udpv4_wan>

        </transport_builtin>

    </domain_participant_qos>

    <datawriter_qos>

        <publish_mode>

            <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>

        </publish_mode>

    </datawriter_qos>

</qos_profile>

Or, you can replace the above configuration by using the built-in XML snippet Transport.UDP.WAN, which does the same thing as the above example: it enables the WAN transport and disables IP fragmentation. You can use that snippet as follows:

<qos_profile name="DisableIPFragmentationWAN">

    <base_name>

        <element>Transport.UDP.WAN</element>

    </base_name>

</qos_profile>

The following XML shows what the Transport.UDP.WAN snippet sets, for reference:

<qos_profile name="Transport.UDP.WAN">

    <base_name>

        <element>BuiltinQosSnippetLib::Transport.UDP.AvoidIPFragmentation</element>

    </base_name>

    <domain_participant_qos>

        <transport_builtin>

            <mask>UDPv4_WAN</mask>

        </transport_builtin>

    </domain_participant_qos>

</qos_profile>

The Transport.UDP.WAN snippet is composed of the Transport.UDP.AvoidIPFragmentation snippet (described in 34.3.1 Avoiding IP-Level Fragmentation), except that it changes the transport to UDPv4_WAN. (See 50.2.3.4 QoS Profile Composition for more information on QoS snippets in XML files.)

Note: Batching does not currently support RTPS fragmentation. If you use batching, you will currently not be able to take advantage of Connext fragmentation. This means that your batch size, including RTPS protocol overhead, has to be limited to the transport MTU. See 34.3 Large Data Fragmentation for more information.