2.2. Discovery Performance for Security

This document describes discovery performance for certain scenarios that use RTI Security Plugins. The metodology and the tests are similar to the ones explained in the Discovery Performance section for RTI Connext DDS Professional.

These numbers should only be used as a first rough approximation, since the results are highly dependent on the hardware, software configuration, and network infrastructure of the tested system.

2.2.1. Time to Complete Discovery

The following graph shows the time it takes to complete endpoint discovery measured for different numbers of DomainParticipants (each with a single endpoint). See the detailed information about the tests below.

Detailed test input

The input parameters chosen for these tests are designed to go through a set of descriptive scenarios, in increasing complexity. These parameters are:

  • Number of hosts: 7

  • Participants in the system: [50 to 300 in steps of 25 participants]

  • Topics in the system: 1

  • Readers per topic: 0.5 * Participants in the system

  • Writers per topic: 0.5 * Participants in the system

Therefore, in this test the number of endpoints is the same as the number of participants, half of them DataReaders and half of them DataWriters.


Detailed results

Time to complete Discovery in 6.1.1 (Seconds)

Participants

No Security

Authentication Only

Secure Discovery

Secure Discovery + Sign

50

2.2760

4.3590

2.8210

2.8080

75

2.3510

4.4000

4.5090

4.4040

100

2.3500

4.5380

4.4580

4.5930

125

2.3840

4.5420

4.6590

4.6930

150

4.4200

4.7710

4.9590

4.8900

175

3.3630

4.8130

5.0310

5.0800

200

4.4520

5.1000

5.3790

7.5920

225

6.5650

5.4150

5.9290

5.7130

250

6.6730

5.7440

8.1850

8.3000

275

6.8960

8.3340

8.9760

9.2530

300

7.0960

9.0950

10.3510

9.9280

325

7.2540

9.9140

11.7060

11.9550

350

7.4240

11.9780

12.7840

12.9820

375

7.5560

14.5670

15.0370

15.1950

400

9.5910

16.2720

17.4220

17.2310

425

9.9360

19.7870

19.8630

20.3970

450

10.1860

22.9100

23.1940

23.7560

475

10.4920

26.4580

26.7080

28.4460

500

10.7430

31.9670

32.1420

32.5750

525

10.9610

35.3200

35.9350

35.8810

550

11.2040

41.2640

40.9620

41.4230

575

11.4250

44.7960

47.5620

46.2960

600

11.8490

50.7430

51.6190

52.1610

625

12.1230

57.3220

57.5790

59.1990

650

12.3980

62.9020

64.8640

65.6290

675

12.8300

68.9850

72.4900

72.7830

700

13.0360

76.9080

79.8790

82.3730

725

13.5360

85.3710

88.8430

90.0690

750

13.9740

94.3260

97.9820

99.4330

775

14.3910

104.9200

108.5520

110.9630

800

15.8700

115.4030

120.2640

122.3370

825

15.3340

126.9260

132.1020

134.9140

850

15.7880

139.1550

146.1490

148.1240

875

16.3960

153.3190

160.5810

163.7480

900

16.9250

167.7830

175.1140

178.1520

925

19.3020

183.8730

191.3930

193.7220

950

18.0240

200.6570

209.6250

213.2910

975

20.5690

214.4280

226.4330

230.0820

1000

20.9180

233.5670

243.7870

248.7710

1025

19.5760

251.8600

266.6490

269.8340

1050

20.2790

274.7790

287.7060

294.5320

Software information

RTI developed a testing framework specifically designed for discovery benchmarking. This framework was used to perform the tests detailed in this document. This framework is capable of running simultaneously different application loads and commands in all the hosts in the experiment. It can collect all of the results and monitor the resource usage of the hosts.

The framework is composed of four main applications: the Manager, Monitor, Agent and Test Application.

The Manager is the initial process to be run. This process launches and coordinates the Agents on each of the test hosts. The Agents are in charge of launching as many Test Applications as the Manager requests. The Manager also requests the Agents to start the tests and shut down.

The Monitor tool is used to visualize the memory, CPU, and discovery data from the Agent and the Test Application. It also indicates problems in the communication (hosts not connected, missed deadlines, etc.).

RTI Connext DDS 6.1.1 is used for compiling and linking. The architecture chosen for the libraries is x64Linux3gcc4.8.2.


Security Profiles

In this set of tests, we compared the discovery times, increasing the number of endpoints, for different levels of security. We will differentiate among four levels:

  • No Security: This test will use RTI Connext DDS Professional without Security Plugins.

  • Secure Libraries, Authentication Only: This test uses Security Plugins and requires authentication, but doesn’t protect any messages (no encryption and no “MAC’ing”). This test uses this governance file:

    <dds>
    <domain_access_rules>
      <domain_rule>
        <domains>
          <id_range>
            <min>0</min>
          </id_range>
        </domains>
        <allow_unauthenticated_participants>TRUE</allow_unauthenticated_participants>
        <enable_join_access_control>FALSE</enable_join_access_control>
        <discovery_protection_kind>NONE</discovery_protection_kind>
        <liveliness_protection_kind>NONE</liveliness_protection_kind>
        <rtps_protection_kind>NONE</rtps_protection_kind>
        <topic_access_rules>
          <topic_rule>
            <topic_expression>*</topic_expression>
            <enable_discovery_protection>FALSE</enable_discovery_protection>
            <enable_read_access_control>FALSE</enable_read_access_control>
            <enable_write_access_control>FALSE</enable_write_access_control>
            <metadata_protection_kind>NONE</metadata_protection_kind>
            <data_protection_kind>NONE</data_protection_kind>
          </topic_rule>
        </topic_access_rules>
      </domain_rule>
    </domain_access_rules>
</dds>

  • Secure Libraries, Secure Discovery In this test, we enable security restrictions for discovery. This is the governance file used:

    <dds>
    <domain_access_rules>
      <domain_rule>
        <domains>
          <id_range>
            <min>0</min>
          </id_range>
        </domains>
        <allow_unauthenticated_participants>FALSE</allow_unauthenticated_participants>
        <enable_join_access_control>TRUE</enable_join_access_control>
        <discovery_protection_kind>ENCRYPT</discovery_protection_kind>
        <liveliness_protection_kind>ENCRYPT</liveliness_protection_kind>
        <rtps_protection_kind>NONE</rtps_protection_kind>
        <topic_access_rules>
          <topic_rule>
            <topic_expression>*</topic_expression>
            <enable_discovery_protection>TRUE</enable_discovery_protection>
            <enable_read_access_control>TRUE</enable_read_access_control>
            <enable_write_access_control>TRUE</enable_write_access_control>
            <metadata_protection_kind>NONE</metadata_protection_kind>
            <data_protection_kind>NONE</data_protection_kind>
          </topic_rule>
        </topic_access_rules>
      </domain_rule>
    </domain_access_rules>
</dds>

  • Secure Libraries, Secure Discovery + Sign This test is similar to Secure Discovery but also adds an rtps_protection_kind of SIGN. This is the governance file used:

    <dds>
    <domain_access_rules>
      <domain_rule>
        <domains>
          <id_range>
            <min>0</min>
          </id_range>
        </domains>
        <allow_unauthenticated_participants>FALSE</allow_unauthenticated_participants>
        <enable_join_access_control>TRUE</enable_join_access_control>
        <discovery_protection_kind>ENCRYPT</discovery_protection_kind>
        <liveliness_protection_kind>ENCRYPT</liveliness_protection_kind>
        <rtps_protection_kind>SIGN</rtps_protection_kind>
        <topic_access_rules>
          <topic_rule>
            <topic_expression>*</topic_expression>
            <enable_discovery_protection>TRUE</enable_discovery_protection>
            <enable_read_access_control>TRUE</enable_read_access_control>
            <enable_write_access_control>TRUE</enable_write_access_control>
            <metadata_protection_kind>NONE</metadata_protection_kind>
            <data_protection_kind>NONE</data_protection_kind>
          </topic_rule>
        </topic_access_rules>
      </domain_rule>
    </domain_access_rules>
</dds>

Hardware information

Eight hosts were used to run the tests: seven to run the discovery applications and one to monitor and log the output information.

All these hosts have the following characteristics:

Dell R340 Servers (13 Units)
Processor: Intel Xeon E-2278G (3.4-5GHz, 8c/16t, 16MB cache, 2 memory channels @2666MHz)
RAM: 4x 16GB 2666MHz DIMM (64GB RAM)
HD: 480GB SATA SSD
NIC 1: Intel 710 dual port 10Gbps SFP

All the hosts were connected to the same 10 Gigabit Ethernet switch.

Some extra tuning was done to improve the network and memory capabilities of the hosts:

net.core.rmem_default=65536
net.core.rmem_max=10485760
net.core.wmem_default=65536
net.core.wmem_max=10485760
net.ipv4.ipfrag_high_thresh=8388608
net.core.netdev_max_backlog=30000

You can find more information about this tuning for a better Connext DDS response on RTI Community here.


QOS used

These are the QoS settings used for the Test Applications and Agents. In these QoS settings, we avoid sending the type code and TypeObject during discovery, relax the lease duration settings for participant discovery, and increase the buffer size of the UDPv4 receive sockets.

<dds>
    <qos_library name="DiscoveryLibrary">
        <qos_profile name="BaseDiscoveryProfile">
            <participant_qos name="BaseParticipantQos">
                <transport_builtin>
                    <mask>UDPv4</mask>
                </transport_builtin>
                <resource_limits>
                    <type_code_max_serialized_length>0</type_code_max_serialized_length>
                    <type_object_max_serialized_length>0</type_object_max_serialized_length>
                </resource_limits>
                <discovery_config>
                    <participant_liveliness_lease_duration>
                        <sec>200</sec>
                        <nanosec>0</nanosec>
                    </participant_liveliness_lease_duration>
                    <participant_liveliness_assert_period>
                        <sec>10</sec>
                        <nanosec>0</nanosec>
                    </participant_liveliness_assert_period>
                    <remote_participant_purge_kind>LIVELINESS_BASED_REMOTE_PARTICIPANT_PURGE
                    </remote_participant_purge_kind>
                    <max_liveliness_loss_detection_period>
                        <sec>10</sec>
                        <nanosec>0</nanosec>
                    </max_liveliness_loss_detection_period>
                </discovery_config>
                <property>
                    <value>
                        <element>
                            <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
                            <value>1048576</value>
                        </element>
                    </value>
                </property>
            </participant_qos>
        </qos_profile>
    </qos_library>
</dds>

2.2.2. Comparison between 6.1.1 and 6.0.1

Due to several improvements added in Connext DDS and Security Plugins in 6.1.0, you will see big improvements in discovery time in 6.1.1 (and 6.1.0). The following graph and tables show the results of the tests above done for both 6.0.1 and 6.1.1.

Note

Note that the numbers used to compare these two releases were taken independently, in a different laboratory, hence the mismatch between these numbers and the ones above See the hardware information for more details.

Time to complete Discovery (Seconds)

Participants

No Security

Authentication Only

Secure Discovery

Secure Discovery + Sign

50

2.7320

3.0650

3.1160

3.3220

75

3.0160

3.5920

3.6760

3.8000

100

3.4170

4.2510

6.4510

6.1540

125

4.2110

8.1120

8.2910

8.7180

150

5.1460

11.2380

10.3900

10.5340

175

6.0260

14.2170

13.2850

13.2770

200

6.8690

15.0870

17.2230

17.1860

225

8.2230

18.6980

20.9340

21.5640

250

9.8220

24.4040

26.5830

26.7730

275

12.1190

28.1240

32.0280

32.5500

300

13.6740

32.6540

37.4390

38.4670

For more information about the improvements that account for these gains, see:

Hardware information

Eight hosts were used to run the tests: seven to run the discovery applications and one to monitor and log the output information.

All these hosts have the following characteristics:

CPU Intel Core Xeon (12 Cores) 3.6GHz
Memory (RAM): 12 GB
OS: CentOS 7

All the hosts were connected to the same Gigabit Ethernet switch.

Some extra tuning was done to improve the network and memory capabilities of the hosts:

net.core.rmem_default=65536
net.core.rmem_max=10485760
net.core.wmem_default=65536
net.core.wmem_max=10485760
net.ipv4.ipfrag_high_thresh=8388608
net.core.netdev_max_backlog=30000

You can find more information about this tuning for a better Connext DDS response on RTI Community here.