${taskforce.name} Avatar
  1. OMG Task Force

DDSI-RTPS 2.5 RTF — Open Issues

Open Closed All
Issues not resolved

Issues Descriptions

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

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

    The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.

    For details on the previous discussion and what was proposed as a resolution see DDSIRTP23-6.

    Overall Approach
    -----------------------
    Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

    • messageLength

    The messageLength indicates the length of the RTPS message
    The rtpsSendTimestamp indicates the time when the message was sent
    The messageChecksum

    Mechanisms to add additional information in future revisions.

    The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

    The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Discriminating the reasons for a GAP

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

    The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

    In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

    Currently there is no way for the receiving application to tell the difference.

    There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

PSM and PIM description of Gap message not matching

  • Status: open  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

    The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

currentGSN.value < lastGSN.value condition seems wrong

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

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value

  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

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

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

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

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Add an INFO_AGE submessage

  • Status: open  
  • Source: Kongsberg Defence & Aerospace ( Ornulf Staff)
  • Summary:

    The INFO_AGE submessage is semantically similar to INFO_TS, but it contains a Duration_t instead of a Time_t. It assigns a time to subsequent submessages that the service may use for functionality like lifespan and sample ordering.

    Transmitting a sample age gives the receiver an inexact timestamp. There will be an unknown time span between the time the sender calculates the age and the time the receiver transforms it back to a local time. If the receiver does no adjustment based on estimated latency, the calculated time will always be too high. However, the error will in practice be bounded and in many scenarios the receiver will have a time that is within one second of the actual sample time.

    Kongsberg uses a submessage like this today for deployments where no correct time source is available. This might be because the system has to be fully operational before a good time source is ready, or because some systems have requirements that mandate that the system clock must be adjustable. We have found that this is a better solution than attempting to have some form of synchronized "DDS time" on the network, because coming up with a network time that works very quickly at startup and is robust to network fragmentation is challenging.

    The use of the INFO_AGE message is enabled by a vendor specific configuration option to the participant containing the publisher. It may either be sent as an alternative to INFO_TS or in combination with INFO_TS to allow the subscriber to determine which time to use an also for compatibility with systems without support for INFO_AGE.

    INFO_AGE allows two features on systems with no time synchronization:

    • Full support for sample lifespan QoS, as long as lifespan is an order of magnitude larger than network latency
    • Partial support for by source timestamp QoS. It may be used to determine that some samples are clearly older than others, in practical use when the time difference is on the order of seconds. When estimated times are within the uncertainty margin, the subscriber needs to treat them as by destination order QoS to avoid surprising behavior when e.g. a writer publishes several samples in quick succession.

    It should be noted that a system based on INFO_AGE with multiple readers and writers on the same topic will have a non-deterministic sample order on the readers.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 22 Jun 2020 12:27 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Incomplete specification of how a Publisher and Subscriber are identified

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

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Unclear specification on how the Publisher GUID is communicated

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

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Update Acknowledgemts, Copyright and Statement of Proof

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

    Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

    We may also want to list contributor's names as we do for other specs.

    Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

    Copyright should be updated to include the companies in the 'Acknowledgments'

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Updated: Wed, 23 Sep 2020 00:10 GMT

Support transport-level RTPS message compression

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

    Some transports have limited bandwidth and may benefit from compressing the RTPS message prior to being sent over the transport.

    This is something that could be added in a reasonably simple manner by considering this part of the transport PSM.

  • Reported: DDSI-RTPS 2.3b1 — Mon, 14 Sep 2020 15:06 GMT
  • Updated: Mon, 14 Sep 2020 15:06 GMT

Revise list of Submessages EntityIDs and PIDs reserved for other specifications

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

    It seems that some ranges reserved by other specifications (e.g. XTypes type service) are missing from RTPS. They should be added:

    9.4.5.1.1.1 for SubmessageIDs
    to 9.3.1.3.1 for the EntityIDs
    Table 9.12 for ParameterIDs

    Maybe always list the same set of specs: DDS Security, XTypes, DDS-RPC? and indicate explicitly if a specification does not reserve anything.

    Also figure out whether new builtin endooints show up under the "availableBuiltinEndpoints" see Table 8.73 also the IDL in 9.3.2
    Right now there is a comment in the IDL that says:

    /* Bits 12-15 have been reserved by the DDS-Xtypes 1.2 Specification
    and future revisions thereof.
    Bits 16-27 have been reserved by the DDS-Security 1.1 Specification
    and future revisions thereof.
    */

    Maybe this needs ti be more explicit and get its own section.

  • Reported: DDSI-RTPS 2.3b1 — Wed, 24 Jun 2020 19:00 GMT
  • Updated: Wed, 24 Jun 2020 19:04 GMT


Editorial corrections

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    7.6 enumerated list 5th bullet

    • The transport will drop m essages if incomplete or corrupted during transfer

    -> messages



    8.2.4

    Table 8.6 - RTPS Entity Attribues

    -> Attributes



    8.2.6

    Table 8.9 - RTPS Endpoint configuration attribues

    -> attributes



    8.3.7.2.5 enumerated list 1st bullet

    • If the DataFlag [...], the serializedPayload element is interpreted as
      the value of the dtat- object.

    -> data-object



    8.3.7.9.2 Table 8.42 2nd row 3rd column (meaning)

    Indicates the protocol used for subsequent Sudmessages.

    -> Submessages



    8.4.2.3.2 1st para 2nd sentence

    This requirement only applies if the Reader
    can accomodate these missing samples in its cache [...]

    -> accommodate



    8.4.3 3rd para 3rd sentence

    This involves a
    trade-off, as improved scalability and reduced memory usage may require additional bandwith usage.

    -> bandwidth



    8.4.10.4.7 fixed font section

    FIND change FROM this.cha;nges_from_writer
    

    -> changes_from_writer



    8.6.2 enumerated list 3rd bullet

    * The meaning of submessageIds cannot be modfied.

    -> modified



    8.7.2.2.4 1st sentence

    Implementations may optimize bandwith usage by applying a time-based filter on the Writer side.

    -> bandwidth



    8.7.4 4th para 1st sentence

    When RTPS sends a Data Submessge to communicate instance state changes it may include only the Key of

    -> Submessage



    8.7.4 6th para numbered list

    1. If the previous update to the instance passed the filter, [...]
    that either includes the data value, or else indicates the IntanceState is ALIVE_FILTERED.

    -> InstanceState



    8.7.9 3rd para

    The RTPS protocol suports this forwarding of messages by including information of the original writer.

    -> supports



    9.1 enumerated list 4th bullet

    • [...]; this allows multiple RTPS endpoints to
      share a single operat- ing-system UDP resource (socket/port) while

    -> operating-system



    9.3.1.2 Mapping of the EntityId_t

    typedef octet OctetArray3[3]; struct {
    

    -->

    typedef octet OctetArray3[3]; 
    struct EntityId_t {
    



    9.4.5.7.1 Flags in the Submessage Header

    Reference to (8.3.6.2).

    -> 8.3.7.4.2



    9.4.5.14.1

    The MulticastFlag is [...]. M=1 means the InfoReplyIp4 also includes a
    multicastRLocator.

    -> multicastLocator



    9.6.1.3 1st sentence

    The port number expresssions use the following parameters:

    -> expressions



    9.6.2.2.1 1st para 2nd sentence

    In order to accomodate vendor specific options [...]

    -> accommodate



    9.6.3.9 p179 ca. 5th para

    The DisposeedFlag is represented with the literal 'D.'

    -> DisposedFlag

  • Reported: DDSI-RTPS 2.3 — Tue, 21 Apr 2020 08:05 GMT
  • Updated: Tue, 26 May 2020 23:20 GMT