DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Open Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 23
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSIRTP26-6 Network amplification DDSI-RTPS 2.5 open
DDSIRTP26-31 Inconsistency in the wire representation of SequenceNumber type fields DDSI-RTPS 2.5 open
DDSIRTP26-32 Typo in Table 9.18 (PID__DOMAIN_ID) DDSI-RTPS 2.5 open
DDSIRTP26-30 Incorrect definition of a user-defined within EntityId_t DDSI-RTPS 2.5 open
DDSIRTP26-29 Wrong data type for serializedPayload in DATAFRAG DDSI-RTPS 2.5 open
DDSIRTP26-28 Introduce a concept of Partitions at the DomainParticipant level DDSI-RTPS 2.5 open
DDSIRTP26-27 The specs and illustration of the ChangeForReader are missing / have been removed DDSI-RTPS 2.5 open
DDSIRTP26-26 Error in formatting pseudo code DDSI-RTPS 2.5 open
DDSIRTP26-25 Handling of non-existent cache changes in logical action DDSI-RTPS 2.5 open
DDSIRTP26-24 Inconsistent use of higuest_sent_seq_num and highestSentChangeSN DDSI-RTPS 2.5 open
DDSIRTP26-23 Inconsistent use of SEQUENCE_NUMBER_INVALID; for highestSentChangeSN DDSI-RTPS 2.5 open
DDSIRTP26-17 Fields writerSet and secureWriterSet are missing in wire representation: DDSI-RTPS 2.5 open
DDSIRTP26-16 Paramter id and length should be unsigned short DDSI-RTPS 2.5 open
DDSIRTP26-14 Masks in table 9.6 (ParameterId subspaces) should be hexadecimal DDSI-RTPS 2.5 open
DDSIRTP26-13 Note on the message wide CRC check DDSI-RTPS 2.5 open
DDSIRTP26-11 Textual error in section 9.4.5.2.1 DDSI-RTPS 2.5 open
DDSIRTP26-10 Description incomplete DDSI-RTPS 2.5 open
DDSIRTP26-12 CRC computation for Checksum128_t undefined DDSI-RTPS 2.5 open
DDSIRTP26-15 Please ignore Implementation Work Blocked flag in issue INBOX-1375 DDSI-RTPS 2.5 open
DDSIRTP26-9 Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher DDSI-RTPS 2.5 open
DDSIRTP26-7 Provide a pre-shared key protection mechanism DDSI-RTPS 2.5 open
DDSIRTP26-5 Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long' DDSI-RTPS 2.5 open
DDSIRTP26-4 Inconsiastent notation used to represent bit positions pictorially DDSI-RTPS 2.5 open

Issues Descriptions

Network amplification

  • Status: open  
  • Source: Trend Micro Inc. ( Federico Maggi)
  • Summary:

    Details available to RTF members

  • Reported: DDSI-RTPS 2.5 — Fri, 24 Sep 2021 13:16 GMT
  • Updated: Tue, 27 Sep 2022 17:20 GMT

Inconsistency in the wire representation of SequenceNumber type fields

  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

    In the wire representation figures of 9.4.5.4 and 9.4.5.5, `SequenceNumber writerSN` is shown as:

    +---------------+---------------+---------------+---------------+
    +           SequenceNumber       writerSN                       +
    +---------------+---------------+---------------+---------------+
    

    as if it only occupies 4 bytes.

    In all other places (9.4.2.6, 9.4.5.6, 9.4.5.7, 9.4.5.8, 9.4.5.14, and 9.6.4.7), SequenceNumbers are represented explicitly as 64-bit values:

    +---------------+---------------+---------------+---------------+
    |                                                               |
    +           SequenceNumber       gapStart                       +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    

    In hindsight, the plus signs does indicate that the field is larger than it looks, but unless there is a clear reason, can those representations be unified to remove potential confusion and provide better readability?

  • Reported: DDSI-RTPS 2.5 — Tue, 23 Aug 2022 15:31 GMT
  • Updated: Wed, 24 Aug 2022 17:03 GMT

Typo in Table 9.18 (PID__DOMAIN_ID)

  • Status: open  
  • Source: Georgia Institute of Technology ( Seulbae Kim)
  • Summary:

    `PID__DOMAIN_ID` in table 9.18 has an extra underscore. It should be `PID_DOMAIN_ID`.

  • Reported: DDSI-RTPS 2.5 — Tue, 23 Aug 2022 19:30 GMT
  • Updated: Wed, 24 Aug 2022 16:08 GMT

Incorrect definition of a user-defined within EntityId_t

  • Status: open  
  • Source: Real Time Innovations ( Samuel Raeburn)
  • Summary:

    Section 9.3.1.2 lists the three pre-defined values of the entity key field in EntityId_t as:

    • ‘8 for user-defined entities.
    • ‘11’ for built-in entities.
    • ‘01’ for vendor-specific entities

    The user-defined entities definition should be '00'.

  • Reported: DDSI-RTPS 2.5 — Mon, 22 Aug 2022 10:22 GMT
  • Updated: Wed, 24 Aug 2022 16:08 GMT

Wrong data type for serializedPayload in DATAFRAG

  • Status: open  
  • Source: Atostek Oy ( Juhana Helovuo)
  • Summary:

    Table 8.42 gives the Structure of the DataFrag Submessage. The last field is specified to have type "SerializedPayload". If this would be the case, the contents of that field should be decodable as a SerializedPayload object, as specified in Section 10, but really the field seems to contain just a fragment of a SerializedPayload. A complete series of fragments must be concatenated to get a valid SerializedPayload. Therefore, the type should be changed to indicate that it is a fragment, not a whole object.

    A similar problem exists in Section 9.4.5.5 DataFrag Submessage.

    More generally, there seems to be confusion in terminology between SerializedPayload / SerializedData / SerializedDataFragment.

    The latter two seem to be suitable for use in the payload field of Data and DataFrag submessages, respectively, and they are defined in 8.3.5.17 -.18, but SerializedPayload is not defined in 8.3.5 at all.

    Section 9.4.2 (PSM) again does not define a mapping for SerializedData / SerializedDataFragment, but for SerializedPayload instead.

    Please clarify the relationship between the aforementioned terms.

  • Reported: DDSI-RTPS 2.5 — Tue, 17 May 2022 12:33 GMT
  • Updated: Thu, 19 May 2022 16:02 GMT

Introduce a concept of Partitions at the DomainParticipant level

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    At the wire-protocol level currently only DataWriters and DataReaders have Partitions.

    It would be useful to have a similar concept/Qos at the DomainParticipant level. This would allow system deployments to control better participant matching.

    While the same could be implemented by adding the the partitions to all Readers and Writers in the Participant the process would be tedious and far less efficient. For example with Participant partitions it would be possible for Participants that do not have a matching partition to avoid doing EndpointDiscovery.

  • Reported: DDSI-RTPS 2.5 — Wed, 16 Mar 2022 23:49 GMT
  • Updated: Wed, 16 Mar 2022 23:49 GMT

The specs and illustration of the ChangeForReader are missing / have been removed

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In previous versions, ChangeForReader was specified and illustrated. The ChangeFromWriter (8.4.10.5) is still in place including its illustrated use (8.4.12.3). Is ChangeForReader removed on purpose or by accident? In my opinion, ChangeForReader should be defined as before.

  • Reported: DDSI-RTPS 2.5 — Thu, 3 Mar 2022 10:05 GMT
  • Updated: Mon, 7 Mar 2022 19:49 GMT

Error in formatting pseudo code

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The if statement on the second line should start on a new line.
    Instead of:
    ```
    ReceiverReceiver.unicastReplyLocatorList =
    InfoReply.unicastLocatorList if ( MulticastFlag )

    { Receiver.multicastReplyLocatorList = InfoReply.multicastLocatorList } else { Receiver.multicastReplyLocatorList = <empty> }
    ```
    this should be:
    ```
    ReceiverReceiver.unicastReplyLocatorList = InfoReply.unicastLocatorList

    if ( MulticastFlag ){ Receiver.multicastReplyLocatorList = InfoReply.multicastLocatorList }

    else

    { Receiver.multicastReplyLocatorList = <empty> }

    ```

  • Reported: DDSI-RTPS 2.5 — Wed, 2 Mar 2022 13:07 GMT
  • Updated: Wed, 2 Mar 2022 21:43 GMT

Handling of non-existent cache changes in logical action

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the version 2.3 specs, a gap is inserted in case a cache change isn't available in the history cache. In the 2.5 specs, only the highest previously sent sequence number is taken into account to determine if agap should be inserted.
    The shown logical actions will fail if the cache change with a_change_seq_num can't be located in the cache. in which case a gap should be inserted as well as in the 2.3 specs. Considering the explanation given for sending a gap because of the HISTORY QoS set to KEEP_LAST in the last paragraph on page 82, one should definitely consider the situation that a cache change is missing.

  • Reported: DDSI-RTPS 2.5 — Mon, 28 Feb 2022 08:47 GMT
  • Updated: Wed, 2 Mar 2022 21:42 GMT

Inconsistent use of higuest_sent_seq_num and highestSentChangeSN

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In 8.4.7.3 and 8.4.7.5, the variable highestSentChangeSN is used for the highest sequence number sent. In 8.4.8.1.4 and subsequent paragraphs, the variable highest_sent_seq_num is used for the same purpose.
    Also, there is a spelling error in the variable's name higuest_sent_seq_num instead of highest_sent_seq_num.

  • Reported: DDSI-RTPS 2.5 — Mon, 7 Feb 2022 11:39 GMT
  • Updated: Mon, 7 Feb 2022 17:24 GMT

Inconsistent use of SEQUENCE_NUMBER_INVALID; for highestSentChangeSN

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    On initialization of the ReaderLocator, the highestSentChangeSN is set to SEQUENCE_NUMBER_INVALID which is not defined in this specification. In 8.4.7.2 RTPS StatelessWriter the function unsent_changes_reset is defined as resetting highestSentChangeSN to the value 0. Either define SEQUENCE_NUMBER_INVALID as being the value 0 and use it also in function unsent_changes_reset or use the value 0 instead of SEQUENCE_NUMBER_INVALID. Or, is there a good erason to make a distinction between SEQUENCE_NUMBER_INVALID and 0?

  • Reported: DDSI-RTPS 2.5 — Mon, 7 Feb 2022 10:01 GMT
  • Updated: Mon, 7 Feb 2022 17:23 GMT

Fields writerSet and secureWriterSet are missing in wire representation:

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In 8.3.8.6 Heartbeat, the fields writerSet and secureWriterSet are defined. The equivalent wire presentation is missing however.

  • Reported: DDSI-RTPS 2.5 — Tue, 25 Jan 2022 15:25 GMT
  • Updated: Tue, 25 Jan 2022 22:18 GMT

Paramter id and length should be unsigned short

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    Both the parameter id and length fields are defined as short. These should be unsigned short.

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 14:57 GMT
  • Updated: Tue, 25 Jan 2022 22:14 GMT

Masks in table 9.6 (ParameterId subspaces) should be hexadecimal

  • Status: open   Implementation work Blocked
  • Source: N/A ( Frans Schneider)
  • Summary:

    The masks used in table 9.6 should be written as 0x8000 and 0x4000 instead of 8000 and 4000

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 13:20 GMT
  • Updated: Tue, 25 Jan 2022 22:11 GMT

Note on the message wide CRC check

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    Using the header_extension submessage to pass the message's CRC seems to me the wrong place. It would be more logical to add the CRC at the end of the message for obvious reasons. First processing the whole potentially large message and then inserting the CRC somewhere in the front, requires extra resources. Also, this makes it unnecessary to first use zero's for the value of the CRC field while calculating the message's CRC. Adding the CRC just to the end of the message, maybe in a submessage of its own if you like, is a much better solution.

    Moreover, the receiver has been designed in such a way that while processing a message it can hand off processed submessgaes right away, which is rather nice. With a message CRC ckheck, either in the header or the tail of the messgae, mitigates this feature since one first has to process the whole message before deciding if the message, and therefor the submessages, is valid. Iff some CRC checking should be implemented, do this at the level of a submessage.

    With a 128 or just 64 bit CRC bit checksum, the designer clearly had huge message sizes in mind, which doesn't seem a good design decision to me.

  • Reported: DDSI-RTPS 2.5 — Thu, 20 Jan 2022 14:01 GMT
  • Updated: Tue, 25 Jan 2022 22:07 GMT

Textual error in section 9.4.5.2.1

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The line

    The value of the UExtension4Flag can be obtained from the expression:
    T = SubmessageHeader.flags & 0x04

    should read:

    The value of the TimestampFlag can be obtained from the expression:
    T = SubmessageHeader.flags & 0x04

  • Reported: DDSI-RTPS 2.5 — Wed, 19 Jan 2022 10:29 GMT
  • Updated: Tue, 25 Jan 2022 21:56 GMT

Description incomplete

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the bullet list, the text of second item seems to be incomplete. It now reads:

    • The GUIDs of Endpoint Groups within a Participant
  • Reported: DDSI-RTPS 2.5 — Tue, 11 Jan 2022 14:50 GMT
  • Updated: Tue, 25 Jan 2022 21:53 GMT

CRC computation for Checksum128_t undefined

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The algorithms for 32 and 64 bit crc checks are defined but the one for 128 bits is missing.

  • Reported: DDSI-RTPS 2.5 — Wed, 19 Jan 2022 14:08 GMT
  • Updated: Tue, 25 Jan 2022 21:27 GMT

Please ignore Implementation Work Blocked flag in issue INBOX-1375

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    Sorry, had this flag checked by accident.

  • Reported: DDSI-RTPS 2.5 — Mon, 24 Jan 2022 14:22 GMT
  • Updated: Tue, 25 Jan 2022 20:39 GMT

Unclear how to discover GROUP_GUID/GROUP_ENTITY_ID from a coherent Publisher

  • Status: open   Implementation work Blocked
  • Source: ZettaScale Technology ( Erik Hendriks)
  • Summary:

    The RTPS V2.5 spec explains how to implement the Group ordering/coherency feature in section 8.7.5 and 8.7.6. In these sections it is explained that the scope of the coherent update (i.e. which coherent Writers the coherent Publishers contains) is communicated by means of the GroupDigest, which is the first part of an MD5 hash of an ordered list of CDR encoded EntityIDs of those Writers.

    In order for the Subscribing side to validate whether all relevant Writers have successfully been discovered, it will create a digest from all EntityIDs of the writers discovered so far, and then compare that to the Digest received from the publisher. Only when the two digests are identical you know that you have successfully discovered all participating Writers.

    Problem for this is that you need to know which Writers belong to which Publisher: you can't just calculate a digest over all discovered Writers because not all discovered Writers might be part of the same group coherent Publisher.

    That means I need to to know the GROUP_GUID or at the very least the GROUP_ENTITY_ID of the Publisher of a Writer in order for me to determine which discovered Writer to include in the digest I calculate to do the comparison.

    However, it is not clear from the spec how this GROUP_GUID or this GROUP_ENTITY_ID is communicated from the publishing side to the subscribing side. The spec introduces a separate PID for both the GROUP_GUID and and the GROUP_ENTITY_ID, but nowhere does it say which one to send out from the Publisher side, or to which message to attach this information. This information is necessary however in order to build an interoperable group coherent implementation.

  • Reported: DDSI-RTPS 2.5 — Wed, 12 Jan 2022 16:02 GMT
  • Updated: Wed, 12 Jan 2022 16:02 GMT

Provide a pre-shared key protection mechanism

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    There is an inherent DoS network amplification attack that exploits peer-to-peer discovery. See https://issues.omg.org/browse/DDSIRTP26-6

    This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.

  • Reported: DDSI-RTPS 2.5 — Fri, 12 Nov 2021 16:24 GMT
  • Updated: Fri, 12 Nov 2021 16:24 GMT

Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long'

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    RTPS version 2.3 updated modified Time_t to have the 'seconds' be of type unsigned long so that there would be no rollover in 2038.

    This matches when it is shown in the IDL definition in 9.3.2.1 'IDL Definitions'

    However Section 9.4.2.9 Timestamps illustrates the 'Timestamp' sub-message element with a 'long' instead of 'unsigned long' for the seconds part. It should be changed to illustrate 'unsigned long' as in:

    Timestamp:

    0...2...........8...............16.............24. .............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                 unsigned long    seconds                      | 
    +---------------+---------------+---------------+---------------+ 
    |                 unsigned long    fraction                     | 
    +---------------+---------------+---------------+---------------+
    
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 23:32 GMT
  • Updated: Thu, 10 Jun 2021 23:32 GMT

Inconsiastent notation used to represent bit positions pictorially

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The spec uses two numbering schemes for bits:

    For example 9.4.1 (Overall Structure)

    0...2...........7...............15.............23. .............31
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    But then in 9.4.4 (Mapping of the RTPS Header)

    0...2...........8...............16.............24.............. 32
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    It should be consistent. The more correct scheme appears to be:

    0...2...........8...............16.............24. .............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

    With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.

  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 22:20 GMT
  • Updated: Thu, 10 Jun 2021 22:20 GMT