The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Transient / Persistent data."

Defer this issue until the next revision

This issue requires additional time to be resolved. In order not to delay the adoption of the other important issues that are already resolved the RTF recommend it is deferred to the next RTF.

The DDSI-RTPS Specification v2.1 does not currently specify how interoperable implementations should deal with Group Coherent updates

Define RTPS Mechanisms for Group Ordered Access and Group Coherent Sets

In order to support GROUP access scope as defined by the DDS specification, the RTPS spec has added the following elements:

• New in-line QoS
  • PID_GROUP_SEQ_NUM sent with DATA and (first) DATA_FRAG submessages
  • PID_GROUP_COHERENT_SET in-line QoS sent with DATA and (first) DATA_FRAG submessages
  • PID_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
  • PID_SECURE_WRITER_GROUP_INFO in-line QoS sent with DATA and (first) DATA_FRAG submessages
• New SubmessageElement: GroupDigest
• Extended HB message
  • New G flag (group info)
  • New fields when G flag is set:
    • currentGSN : SequenceNumber
    • firstGSN : SequenceNumber
    • lastGSN : SequenceNumber
    • writerSet : GroupDigest
    • secureWriterSet : GroupDigest
• Extended GAP message
  • New G flag (group info)
  • New fields when G flag is set:
    • gapStartGSN : SequenceNumber
    • gapEndGSN : SequenceNumber
• New fields WriterProxy::remoteGroupEntityId, ReaderProxy::remoteGroupEntityId
  • Uses previously deprecated PID_GROUP_ENTITYID

Title: Must send GAP when filtering on writer-side regardless of reliability QoS setting
Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
This issue is not currently in a state to be resolved. What follows are various thoughts on the issue and possible solutions to be discussed. This issue will not be resolved in time for the finalization task force and is included here to be documented for the revision task force.
Discussion topic: what are DDS semantics for combining filtering with the deadline QoS?
Should the deadline be triggered when all samples during the deadline period were filtered out?
That is, does deadline require at least one sample to arrive every deadline period seconds that passed the filter?
Or is the deadline satisfied when any sample arrives within the period, whether filtered out or not?

If deadline only applies to samples that pass the filter, RTPS needs no changes, simply use the GAP subMessage to avoid incorrect onDataLost callbacks.
If not, we run into a problem when using keyed DataWriters and finite deadlines. As the deadline applies on a per instance basis, the Reader expects at least one update for every instance, even when none of the updates for a particular instance pass the filter. A GAP message does not indicate for which instance an update was filtered out, so it cannot be used by the Reader to verify the deadline constraint. Instead, we should consider using an empty DATA message instead, possibly with a flag that states the update did not pass any filter. This would also be useful to add a new instance state NOT_ALIVE_FILTERED or so later on to the DDS spec.
Another possibility would be to add a list of KeyHashes to the GAP message. SO that a GAP that is caused by a CFT actually encodes the instances that are being gapped. This would not cause incorrect firings of the DEADLINE and as a result would maintain ownership of instances even if they are filtered out…
There are two ways to do this.
Either we separate GAPs that correspond to filtered samples from those that correspond to irrelevant samples. So in effect we have two kinds of GAP messages
Or we list explicitly the sequence number of each filtered message along with its KeyHash.
Not clear what would be easier implementationwise. The samples that have been filtered are still on the writer so it appears that either implementation would work.
Option (1) would save putting the sequence number with each KeyHash. This can be 4 or 8 bytes per instance, depending on whether we put the sequence number as is, or we encode it as an increment
Option (2) would cause additional GAP submessages to be sent which is an overhead of 28 bytes. Not clear what is less costly…
Also, if we use Option(1), then the messages that represent real GAPs can be sent via multicast; but this is only likely to occur when late joiners appear as normally there would be no "irrelevant" gaps if data is published immediately. Moreover we can in practice still do this and separate the GAP messages that represent real GAPs from the ones that don't. Option 1 does not force us to combine, just provides the means to do so…
Option (2) has the problem that in certain edge cases the overhead is significant. For example if each we have a irrelevant-sample GAP followed by a filtered sample, followed by an irrelevant sample gap, etc. then we end up sending one GAP message per filtered sample with is 28 bytes of overhead per filtered sample versus a single GAP with 4 bytes of overhead per filtered sample. Also the processing is much more efficient as each GAP message is dispatched separately up the receiver's stack.
For this reason it appears that Option 1 is more flexible, and the overhead is more stable. Opt
Proposal(s):
Always send GAPs for filtered-out messages (both in the BestEffort and in the RELIABLE) cases
If the type is Keyed, then the GAP also includes at the end a sequence of :
struct FilteredSampleDesc

;
The GAP message gets two additional flags:
KeyHashFlag
indicates the presence of the KeyHashPrefix
FilteredSamplesFlag
Indicates the presence of the sequence< FilteredSampleDesc>
An issue needs to be filed against the DDS spec to clarify:
(a) Whether the deadline as specified by a DataReader should apply to the samples that pass the DataReader filter or to the samples sent by any writer?
(b) Whether a new instance_state ALIVE_FILTERED should be added such that the DataReader can determine that a sample was filtered and potentially take action on that.
(c) Whether an API or a QoS should be added to the DataReader to allow the DataReader to remove the instance information for instances with state ALIVE_FILTERED after all samples are taken. This allows resources to be conserved in the case where once filtered we expect the instance to remain filtered and also allows a reader to be notified if the instance becomes unfiltered.
(d) Weather to add a filtered_generation_count that the instance has becomed ALIVE after being in the ALIVE_FILTERED

Resolution:
T4 should include code and description that states that when the sample is not relevant, send a GAP…same for the stateful best effort writer.
Revised Text:

Introduce a mechanism to inform a Reader that an instance is filtered

Extend the StatusInfo_t that is sent via inline Qos (PID_STATUS_INFO) such that it can be used to indicate that an instance has been filtered by a reader. This extends the current usage to send DISPOSE and UNREGISTER messages.

Add an issue to the DDS RTF 1.5 to introduce the concept of ALIVE_FILTERED Instance state to complement the existing ones (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS).

Define more precisely when a writer that does writer-side content filter should send the DISPOSE, UNREGISTER, and FILTERED messages.

1. Section: 8.3.6.3, Bullet 2 and Footnote 2
Page: 43
Change: PROTOCOL_RTPS is not defined by PSM

2. Section: 8.3.7.3.2, Table 8.35
Page: 50
Change: KeyFlag is missing from the table

3. Section: 8.3.7.3.2, Table 8.35
Page: 51
Change: Remove the line "Present only if DataFlag is set in the header", as DataFrag has no such flag. Remove the line "Present only if either the DataFlag or the KeyFlag are set in the header", as DataFrag has no DataFlag. In the first bullet point replace "If the DataFlag is set" with "If the KeyFlag is not set".

4. Section: 8.4.1
Page: 63
Change: Section 8.4.13 (Writer Liveliness) is missing from this list.

5. Section: 8.4.7.2
Page: 75
Change: The paragraph above the table should be changed from using Locator_t to ReaderLocator (the table was changed in a previous revision).

6. Section: 8.4.7.2.2, 8.4.7.2.3
Page: 76
Change: Locator_t in these sections should be ReaderLocator

7. Section: 8.4.7.3, Table 8.51
Page: 77
Change: In figure 8.15, type of locator is Locator_t[*] but the [*] is missing from this table (8.51) and the text should reflect the actual cardinality

8. Section: 8.4.9.2
Page: 93
Change: The sentence fragment "Submessages are used..." is nonsensical, it should be removed.

9. Section: 8.5.3.3, Figure 8.29
Page: 129
Change: Remove figure 8.29, it is a duplicate of figure 8.28

10. Section: 9.4.5.3, block diagram
Page: 170
Change: Flag "K" is missing from the flags byte

11. Section: 9.6.2.1
Page: 180
Change: The wire-representation diagram is missing the participantGuidPrefix and kind fields (also see OMG Issue 12501)

12. Section: 9.6.2.2, Table 9.10
Page: 182
Change: remoteWriterGuid belongs to WriterProxy, not ReaderProxy

13. Section: 9.6.2.2, Table 9.10
Page: 182
Change: Table 9.10 caption is incorrect, looks like it was copied from 9.11

14. Section: 9.6.3.2, Table 9.16
Page: 190
Change: KeyHashSuffix does not exist; remove this row from the table. The row for SerializedData should be sufficient to describe the use of PID_COHERENT_SET.

Fix Editorial Issues

There are a number of minor editorial issues that need to fixed. This issue was created to resolve them.

Key attributes and Regular attributes of a topic should be individually de-serializable (or at least make the keyhash compulsory)

[Nature] Architectural
[Severity] Major

[Description]
The "DDS Interoperability Wire Protocol v2.1" defines a a serialization format for topic types in which
it is not easy, nor efficient, to simply get access to the key of a given topic. This has to do with how CDR
serializes structs but could be worked around with the new X-Types specification.
In essence the problem is that some applications such as DDS routers (such as the PrismTech BlendBox)
require to perform some operations that while requiring a knowledge of the instance do not require the deserialization
of the data payload.

[Resolution]
For DDS implementation compatible with the X-Types ensure that the regular data attributes and the key attributes are serialized
in different chunks and thus individually accessible in an efficient manner – meaning to access the key I would prefer not to scan all
the regular attributes.

For non X-Types compatible DDS implementations make the KeyHash compulsory, meaning require DDS compliant implementation to
always send a key-hash along with a Data submessage.

No immediate need to add individual serialization of keys and regular attributes

The RTF does not see an immediate need to add the proposed functionality to the specification.

In section 8.7.9 of the DDSI/RTPS v2.1 protocol is described the KeyHash sub-message-element representing the MD5 hash of the key for the Data sub-message to which it belongs.

The specification does not mandate the use of the KeyHash all keyed topics – implementations are free to include it or not. However, if implementations are not including the KeyHash the only way to get a clue on the Topic Instance to which the received samples belongs is to de-serialize the payload.

This leads two at least two problems, (1) DDSI/RTPS routers are forced to de-serialize the data payload even if no content transformation have to be performed and (2) DDS Implementations are forced to deserialize eagerly in order to manage instances, thus preventing DDS implementations to do lazy deserialization (which is now possible with the API provided by the new C++/Java PSM).

The suggested resolution is to require that Data SubMessage for keyed topic shall always include the KeyHash submessage element.

No immediate need to require sending the Keyhash with each sample

The RTF does not see an immediate need to add the proposed functionality to the specification.

Page: 92
Change: Figure 8.18 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

Add descriptions of when Best Effort Writers Send GAP messages

The Best-Effort Stateless and Stateful Writer Behaviors should include logic for when a GAP message is sent, similar to the logic already present for their Reliable counterparts.

Page: 77
Change: Unlike other tables of operations in this section, none of these operations are described in the text of the section

Add missing descriptions of the ReaderLocator operations in Table 8.52

Add missing descriptions of the ReaderLocator operations in Table 8.52, in a similar manner to the other kinds of operations that are defined in this section.

Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. In general, encapsulation means adding specific prefix bytes to the on-the-wire representation of data. This prefix can be used by the receiver to understand the format of the following bytes. The majority of uses of “encapsulation” in the specification do not agree with this meaning. This issue seeks to fix that by using the simpler term of “encoding” in place of “encapsulation.”

Encapsulate
-----------------

Section: 8.3.2, Table 8.13, Count_t row
Page: 30
Change: replace “'encapsulate'” with “'hold”'

Section: 8.3.3.2, Table 8.15, flags row
Page: 34
Change: replace '“encapsulate”' with “'encode”' in two places

Section: 8.3.5.1
Page: 37
Change: replace “'encapsulate'” with '“contain'”

Section: 8.3.5.9, Paragraph 1
Page: 41
Change: replace “encapsulate” with “'contain'”

Section: 8.3.7.9.2, Table 8.41, protocolVersion and VendorId rows
Page: 59
Change: replace “'to encapsulate subsequent Submessages'” with “"for subsequent Submessages”"
Change 'vendor that encapsulated subsequent submessages' with “'vendor that originated the subsequent submessages' ”

Section: 8.4.10.3
Page: 105
Change: replace “'encapsulated”' with “'maintained”'

Section: 8.4.11.1.2
Page: 110
Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

Section: 8.4.12.1.2
Page: 112
Change: replace 'the DATA message encapsulates' with 'the DATA message contains'

Section: 8.5.3.2, Table 8.73, expectesInlineQos row
Page: 126
Change: replace '“encapsulated”' with '“included'”

Section 9.4.2.12
Page: 166
Change: replace 'process used to encapsulate' with 'process used to encode'

Section: 9.6.2.2, Paragraphs 4-5
Page: 181
Change: replace “'encapsulates'” with “'contains'”; replace “'encapsulated'” with “'represented'” (twice)

Section: 9.6.2.2.2
Page: 182
Change: replace “'used to encapsulate the data'” with '“used for the data'”

Section: 9.6.3
Page: 187
Change: replace “'are encapsulated'” with “'are contained'”

Section: 9.6.3.3
Page: 190
Change: replace “'any unfilled bits in the KeyHash_t after all the key fields have been encapsulated shall be set to zero' with 'any unfilled bits in the KeyHash_t shall be set to zero”'

Page: 191
Change: replace “'encapsulated as' with 'represented as'

Section: 10
This is handled on a separate issue.

Encapsulation
-------------------

Section 6.2 change 'data encapsulation' to 'data representation' (twice)

Section 8.3.3 change 'transport encapsulation' to 'transport headers'

Section 8.3.5.9 change 'The encapsulation' to 'the representation'

Section 8.3.5.12 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'
Section 8.3.5.13 change 'For additional information on data encapsulation see ...' to 'For additional information see ...'

Table 8.34 change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

Table 8.35 serializedPayload row:
Change 'Encapsulation of a consecutive ...' with ' A consecutive ...'
Change 'contains the encapsulation of the ...' to 'contains the ...' (twice in serializedPayload row).

Section 8.4.11.1.1 and 8.4.11.1.2
Change 'The encapsulation is described' to 'The representation is described' (once on each section)

Section: 9.4.2.11, Paragraphs 5, 7, 9
Page: 165
Change: “'CDR encapsulation”' with 'CDR representation' and 'ParameterList encapsulation' with 'ParameterList representation'

Change 'These are two predefined values of the parameterId used for the encapsulation' with 'These are two predefined values of the parameterId:'

Section 9.5 Change title to "Mapping to UDP/IP Transport Messages"
Change body to:
When RTPS is used over UDP/IP, each UDP/IP datagram shall contain exactly one or more complete RTPS Messages.

Note: This is a change. Currently the requirement is one datagram one RTPS message.

Section: 9.6.3.3
Page: 190-191
Change: replace “'“encapsulation'” with '“representation'” (seven times)

Replace all uses of any form of 'Encapsulate'

Encapsulation has a precise technical meaning from the CORBA spec (formal/11-11-02 section 9.3.3) and a similar meaning from chapter 10 of RTPS, neither of which matches most of the other uses of “encapsulation” throughout the RTPS spec. We are therefore replacing all uses of any form of the word 'encapsulate' with a different word.
Three general rules of thumb were followed:

1. In cases describing the contents of SubmessageElements or messages, we have replaced encapsulate with 'contain'.
2. Anywhere that said 'data encapsulation' or 'CDR encapsulation' is replaced with 'data representation'.
3. We have removed the phrase containing encapsulation all together in places where it was used unnecessarily.

All other situations were dealt with on a case-by-case basis

This distinction is important for DDS, but not relevant for RTPS. There are places where RTPS deals with the Key as an independent unit of data (KeyFlag, etc.), but those are not relevant to the TopicKind_t which seems to be an artifact of an older version of the specification. The current protocol as written in this specification works the same way for both With Key and No Key topics. This issue seeks to remove the Topic Kind concept entirely from the specification.
1. Section: 8.2.1.2, Table 8.2
Page: 14
Change: remove the table row for TopicKind_t
2. Section: 8.2.1.3, Figure 8.2
Page: 16
Change: remove the topicKind attribute in Endpoint
3. Section: 8.2.5, Figure 8.5
Page: 21
Change: remove the topicKind attribute in Endpoint
4. Section: 8.2.6, Table 8.9
Page: 23
Change: remove the table row for TopicKind_t
5. Section: 8.2.9.1, Figure 8.6
Page: 25
Change: remove the if() statements for W::topicKind
6. Section: 8.2.9.1.3-4
Page: 26-27
Change: remove the if() statements for the_rtps_writer.topicKind and the paragraphs “This operation has no effect if the topicKind==NO_KEY).”
7. Section: 8.3.3, Figure 8.8
Page: 31
Change: remove NoKeyData and NoKeyDataFrag
8. Section: 8.3.7, Bullets 1-2,4
Page: 43
Change: remove the text “(NO_KEY Reader/Writer or WITH_KEY Reader/Writer)”
9. Section: 8.3.7.2
Page: 47
Change: remove the text “(NO_KEY or WITH_KEY)”
10. Section: 8.3.7.3
Page: 49
Change: remove the text “(NO_KEY or WITH_KEY)”
11. Section: 8.3.7.2, 3rd Bullet
Page: 63
Change: remove the text referring to “keyed topics”
12. Section: 8.4.4
Page: 69-70
Change: remove all references to topicKind, WITH_KEY, NO_KEY, etc.
13. Section: 8.4.7.1, Figure 8.15
Page: 72
Change: remove the topicKind attribute in Endpoint
14. Section: 8.4.8.1
Page: 83
Change: remove “WITH_KEY”
15. Section: 8.4.8.1, Figure 8.16
Page: 84
Change: remove “WITH_KEY”

16. Section: 8.4.8.2
Page: 85
Change: remove “WITH_KEY” and “NO_KEY”
17. Section: 8.4.8.2, Figure 8.17
Page: 86
Change: remove “WITH_KEY”
18. Section: 8.4.9.1
Page: 90
Change: remove “WITH_KEY” and “NO_KEY”
19. Section: 8.4.9.1, Figure 8.18
Page: 90
Change: remove “WITH_KEY”
20. Section: 8.4.9.2
Page: 93
Change: remove “WITH_KEY” and “NO_KEY”
21. Section: 8.4.9.2, Figure 8.19
Page: 94
Change: remove “WITH_KEY”

22. Section: 8.4.10.1, Figure 8.21
Page: 102
Change: remove the topicKind attribute in Endpoint

23. Section: 8.4.11.1
Page: 109
Change: remove “WITH_KEY” and “NO_KEY”
24. Section: 8.4.11.1, Figure 8.22
Page: 110
Change: remove “WITH_KEY”

25. Section: 8.4.12.1
Page: 111
Change: remove “WITH_KEY” and “NO_KEY”
26. Section: 8.4.12.1, Figure 8.23
Page: 111
Change: remove “WITH_KEY”

27. Section: 8.4.12.2
Page: 113
Change: remove “WITH_KEY” and “NO_KEY”

28. Section: 8.4.12.3, Figure 8.25
Page: 117
Change: remove “NOKEYDATA” alternative

29. Section: 8.5.3.3, Tables 8.74 and 8.75
Page: 129
Change: remove topicKind rows from both tables

30. Section: 9.3.2, Table 9.4
Page: 155
Change: remove the “TopicKind_t” row

Limit the use of TopicKind to the places where it matters

The protocol works the same whether or not a Topic is keyed; the distinction was therefore unnecessary in many places and was removed.

Section 9.6.3.3 KeyHash (PID_KEY_HASH) says that the KeyHash is either computed as the CDR Big-Endian encapsulation of all the Key fields in sequence, or else as the MD5 of that "CDR Big-Endian encapsulation of all the Key fields in sequence" the decision is based on whether the "CDR Big-Endian encapsulation of all the Key fields in sequence" for that data-type is known to always fit into the 16-byte KeyHash.

However the text in the first bullet says "If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits, then the KeyHash shall be computed...

This is misleading as it leave indeterminate the case when the "the maximum size of the sequential CDR encapsulation of all the key fields" is exactly 128 bits. In this case if the sentence is interpreted to mean "strictly less than 128" then an MD5 should be used. If it is interpreted to mean "less or equal" then no MD5 should be applied.

Unfortunately this situation occurs on the builtin-topic types because the GUIDs are exactly 16 bytes.

Proposed Resolution:
In Section 9.6.3.3 KeyHash (PID_KEY_HASH). In the first bullet, replace:
"If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less than 128 bits,"

With
"If the maximum size of the sequential CDR encapsulation of all the key fields is guaranteed to be less or equal than 128 bits,"

Clarify the KeyHash computation in the case of a CDR encapsulation of exactly 128 bits

The language describing when to use an MD5 to compute the KeyHash has been clarified to reflect that no MD5 should be used is the serialized length of the key fields is less that or equal to 128 bits, as opposed to strictly less than.

Page: 120
Change: Fragment size should be allowed to be equal to (instead of strictly greater than) 1KB, also define KB as 1024 bytes to avoid the KB/KiB issue (1000 vs. 1024).

Remove the lower bound for fragment sizes

We see no need to specify the lower bound for fragment sizes so we will remove that requirement.

Page: 85
Change: Figure 8.16 notes that transition T4 can send a GAP, but this section doesn't describe when/how to send a GAP.

This issue is resolved as part of DDSIRTP23-20

This issue is resolved as part of DDSIRTP23-20

Page: 184-187
Change: The following RTPS fields lack a mapping: ParticipantProxy::guidPrefix, ReaderProxy::remoteReaderGuid, WriterProxy::remoteWriterGuid. Table 9.10 indicates that they are optional, but they are not possible to encode without a mapping. Also, DiscoveredReaderData::contentFilterProperty (AKA DiscoveredReaderData::contentFilter in the PIM: these should be consistent) is lacking a mapping

Cleanup up missing and unused ParameterId mappings

Add a missing PID_ENDPOINT_GUID and map SubscriptionBuiltinTopicData::key and PublicationBuiltinTopicData::key to it.

Add missing mapping of DiscoveredReaderData::contentFilterProperty, TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation

Remove the mapping of SubscriptionBuiltinTopicData::lifespan, which is not present in DDS

Page: 185
Change: The following DDS fields lack a mapping: TopicBuiltinTopicData::topic_data, SubscriptionBuiltinTopicData::durability, PublicationBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::ownership, SubscriptionBuiltinTopicData::presentation, and the "key" field in Publication, Subscription, and Topic. Also, the mapped DDS field SubscriptionBuiltinTopicData::lifespan does not exist in DDS

Duplicates DDSIRTP23-8

The resolution of DDSIRTP23-8 covers the resolutions of the missing/unnecessary mappings described in DDSIRTP23-9

Page: 184
Change: Duration_t (used for PID_PARTICIPANT_LEASE_DURATION) is not defined in the PSM. Use Time_t instead?

Define a PSM Mapping for Duration_t

A PSM mapping of Duration_t has been defined in Table 9.4, specifying that the representation on the wire should be NTP.

Page: 183-184
Change: IPv4Address_t and Port_t are not defined anywhere in the specification

*Deprecate PIDs *

There are a number of PIDs for address and port fields that are no longer necessary or used since the information that they identify is sent in the form of a Locator, we are therefore deprecating these PIDs:
PID_MULTICAST_IPADDRESS
PID_DEFAULT_UNICAST_IPADDRESS
PID_DEFAULT_UNICAST_PORT
PID_METATRAFFIC_UNICAST_IPADDRESS
PID_METATRAFFIC_UNICAST_PORT
PID_METATRAFFIC_MULTICAST_IPADDRESS
PID_METATRAFFIC_MULTICAST_PORT

PID_PARTICIPANT_BUILTIN_ENDPOINTS is also not used and will be deprecated. Implementations are using PID_BUILTIN_ENDPOINT_SET instead.

Page: 182
Change: This section refers to a non-existent "key parameter" in the Data submessage.

Clarify what the "key" parameter in section 9.6.2.2 is referring to

In section 9.6.2.2 the phrase '"key" parameter' is referring to the parameters listed in table 9.10, the language used to indicate this should be clarified.

Page: 181
Change: This section under-specifies the key fields for all four data types. The "inherited" DDS structures do not provide a key field that is useful for RTPS because it is vendor-specific. This section should describe what a "key only" (KeyFlag==1) Data Submessage should contain as its payload for both SPDP and for all 3 types of SEDP. Table 9.13 indicates that Built-In Topic Keys can be encoded as a GUID, which has no correspondence to the actual definition of Built-In Topic Keys.

Describe the contents of the key-only Data Submessage for each of the Builtin Topic Types

Descriptions have been added to clarify that a key-only submessage for each of the Built-in Topic types requires:
PID_PARTICIPANT_GUID (for SPDP)
PID_ENDPOINT_GUID (for SEDP)

Page: 181
Change: Duration_t (used for leaseDuration) is not defined in the PSM. Use Time_t instead?

Duplicates DDSIRTP23-10

Merged with DDSIRTP23-10

Page: 147
Change: There is no such "directed" or "peer-to-peer" function described by the DDS spec, therefore none is available to the user. If such a function should be used by RTPS to implement DDS communication, its use by RTPS must be described here. Otherwise remove this section.

Remove explicit dependency on DDS api

Accept suggested approach of editing section 8.7 to remove explicit dependency on DDS APIs

Page: 127
Change: In the row for defaultUnicastLocatorList, "at least one Locator must be present" constrains implementations unnecessarily. As long as each Endpoint has a locator, there is no need for the participant to have a default locator

Do not make the defaultUnicastLocatorList optional

As the proposed change breaks backwards compatibility, the decision has been made to defer this issue to a major revision of the protocol. The label RTPS3 has been added to indicate this and to aid in future searches of issues like this one.

Page: 126-127
Change: In the figure and the table, BuiltinEndpointSet_t is already a "set" so it should not also be an array with "[*]"

Already fixed in 2.2

Already fixed in 2.2

Page: 123
Change: Scope of counts is underspecified: is a Heartbeat count scoped to one Writer; is an AckNack/NackFrag count scoped to a Reader itself or to a Reader's conversation with a given Writer?

Clarify the scope of the HeartBeat and AckNack Submessage Count fields and how to deal with overflow in the count fields

The scope of the count fields of the HeartBeat and AckNack have been clarified to make it clear that it is up to the implementation if it keeps track of each endpoint separately or reuses the epoch across endpoints as long as the epoch changes from the previous one sent to an endpoint.

Clarification as to how overflow in these fields should be handled by an implementation has also been added.

In table 9.4 the the PSM RTPS define ReliabilityKind_t defines RELIABLE as having the value 3. However the Wireshark packet dissector defines ReliabilityKind_t RELIABLE as having the value 2.

In table 9.4 the PSM RTPS specification defines LOCATOR_KIND_UDPv6 having the value 2. However the Wireshark packet dissector defines LOCATOR_KIND_UDPv6 as having the value 8.

The vendors interoperate and used Wireshark to fine-tune their discovery therefore they are actually using the Wireshark-defined values rather than the ones in table 9.4

Proposed resolution:

Modify Table 9.4 entry for ReliabilityKind_t from:
#define RELIABLE 3

to
#define RELIABLE 2

Modify Table 9.4 entry for Locator_t from:
#define LOCATOR_KIND_UDPv6 2

to
#define LOCATOR_KIND_UDPv6 8

*Change the value of RELIABLE_RELIABILITY and add a description of how it is marshalled *

RELIABLE_RELIABILITY is currently defined with the value 3, however in practice all implementations are using 2, so the value has been changed in the spec.

It was also noted that the values in the RTPS spec differ from the API-level values defined in the DDS spec. Therefore, a description of how to marshal the DDS-defined ReliabilityQosPolicy on the wire.

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
This type is actually a set of boolean flags and so should be renamed to reflect its actual intention. Additionally, the description for this type is missing from Table 9.4.

Proposed Resolution:
Rename the type from BuiltinEndpointKind to BuiltinEndpointSet_t. Provide an entry in Table 9.4 to describe the type.

Revised Text:
In Table 8.77, the third row from the end (the cell in the first column reads "availableBuiltinEndpoints"), replace "BuiltinEndpointKind" with "BuiltinEndpointSet_t."

Replace Figure 8.26 with:

In Table 9.4, add the following row to the end of the table:

BuiltinEndpointSet_t Mapping of the type
typedef unsigned long BuiltinEndpointSet_t;
where
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_ANNOUNCER 0x00000001 << 0;
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_DETECTOR 0x00000001 << 1;
#define DISC_BUILTIN_ENDPOINT_PUBLICATION_ANNOUNCER 0x00000001 << 2;
#define DISC_BUILTIN_ENDPOINT_PUBLICATION_DETECTOR 0x00000001 << 3;
#define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_ANNOUNCER 0x00000001 << 4;
#define DISC_BUILTIN_ENDPOINT_SUBSCRIPTION_DETECTOR 0x00000001 << 5;
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_ANNOUNCER 0x00000001 << 6;
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_PROXY_DETECTOR 0x00000001 << 7;
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_ANNOUNCER 0x00000001 << 8;
#define DISC_BUILTIN_ENDPOINT_PARTICIPANT_STATE_DETECTOR 0x00000001 << 9;
#define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_WRITER 0x00000001 << 10;
#define BUILTIN_ENDPOINT_PARTICIPANT_MESSAGE_DATA_READER 0x00000001 << 11;

This issue was already resolved

This issue was already resolved as part of the first FTF. It must have been incorrectly imported when tranitioning to Jira

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

Resolution:
Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

Revised Text:

Add to table 9.4:

Type PSM Mapping
OriginalWriterInfo_t struct

OriginalWriterInfo;

Append to table 9.13:
Name ID Type
PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

Add new section:

8.7.6 Original Writer Info

A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

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

OriginalWriterInfo_t
attribute type value
originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

No Data Available

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

Resolution:
Add parameter Id for Type Max Sample Size Serialized

Revised Text:

Append to Table 9.11:
Name ID Type
PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

No Data Available

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The current Writer liveliness mechanism piggybacks on SPDP messaging. As RTPS should also be able to support other discovery protocols beyond SPDP, including a static configuration, this is not the best approach.
It is true that all implementations must support at least SPDP, but if a customer wants to disable it (e.g. no need to interoperate with a different vendor so it possible to use a different protocol exclusively), this should not affect the DW liveliness mechanism. To some extent, it does not, but sending SPDPDiscoveredParticipantData to maintain a DWs liveliness is wasteful, especially if SPDP is not even used.
Resolution:
Update the Writer liveliness protocol to be independent of Discovery.
Revised Text:
Since this change is lengthy, the editorial instructions appear in a blue font to help the reader distinguish them from document content.

· Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the SPDPDiscoveredParticipantData) at a rate faster than the smallest lease duration among the Writers.

with:

DDS_AUTOMATIC_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. For a given Participant, in order to maintain the liveliness of its Writer Entities with LIVELINESS QoS set to AUTOMATIC, implementations must refresh the Participant's liveliness (i.e., send the ParticipantMessageData, see Section 8.4.13.5 for details) at a rate faster than the smallest lease duration among the Writers.

· Section 8.7.2.2.3, first paragraph, first bulleted item, replace:

DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the SPDPbuiltinParticipantWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the SPDPDiscoveredParticipantData) and add the PID_PARTICIPANT_MANUAL_LIVELINESS_COUNT in-line QoS, where the value of the in-line QoS is incremented each time.

with:

DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS : liveliness is maintained through the BuiltinParticipantMessageWriter. If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of them. The period for this check equals the smallest lease duration among the Writers. If any of the operations were called, implementations must refresh the Participant's liveliness (i.e send the ParticipantMessageData, see Section 8.4.13.5 for details).

· Section 8.5.2, change the title from "RTPS built-in Endpoints" to "RTPS built-in Discovery Endpoints"
· Add the following row to the end of Table 8.50:

ParticipantMessageData Type used to hold data exchanged between Participants. The most notable use of this type is for the Writer Liveliness Protocol.

· Insert new Section following 8.4.12 (so a new 8.4.13) with the following content:

8.4.13 Writer Liveliness Protocol
The DDS specification requires the presence of a liveliness mechanism. RTPS realizes this requirement with the Writer Liveliness Protocol. The Writer Liveliness Protocol defines the required information exchange between two Participants in order to assert the liveliness of Writers contained by the Participant.

All implementations must support the Writer Liveliness Protocol in order to be interoperable.

8.4.13.1 General Approach
The Writer Liveliness Protocol uses pre-defined built-in Endpoints. The use of built-in Endpoints means that once a Participant knows of the presence of another Participant, it can assume the presence of the built-in Endpoints made available by the remote participant and establish the association with the locally-matching built-in Endpoints.

The protocol used to communicate between built-in Endpoints is the same as used for application-defined Endpoints.

8.4.13.2 Built-in Endpoints required by the Writer Liveliness Protocol
The built-in Endpoints required by the Writer Liveliness Protocol are the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. The names of these Endpoints reflect the fact that they are general-purpose. These Endpoints are used for liveliness but can also be used for other data in the future.

The RTPS Protocol reserves the following values of the EntityId_t for these built-in Endpoints:
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER
ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER

The actual value for each of these EntityId_t instances is defined by each PSM.

8.4.13.3 BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader QoS
For interoperability, both the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader use the following QoS values:
· reliability.kind = RELIABLE_RELIABILITY_QOS
· durability.kind = TRANSIENT_LOCAL_DURABILITY_QOS
· history.kind = KEEP_LAST_HISTORY_QOS
· history.depth = 1

8.4.13.4 Data Types associated with the built-in Endpoints used by the Writer Liveliness Protocol

Each RTPS Endpoint has a HistoryCache that stores changes to the data-objects associated with the Endpoint. This is also true for the RTPS built-in Endpoints. Therefore, each RTPS built-in Endpoint depends on some DataType that represents the logical contents of the data written into its HistoryCache.

Figure X defines the ParticipantMessageData DataType associated with the RTPS built-in Endpoints for the "DCPSParticipantMessage" Topic.

Figure X The ParticipantMessageData structure.

8.4.13.5 Implementing the Writer Liveliness Protocol using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader

The liveliness of a subset of Writers belonging to a Participant is asserted by writing a sample to the BuiltinParticipantMessageWriter. If the Participant contains one or more Writers with a liveliness of AUTOMATIC_LIVELINESS_QOS then one sample is written at a rate faster than the smallest lease duration among the Writers sharing this QoS. Similarly, a separate sample is written if the Participant contains one or more Writers with a liveliness of MANUAL_BY_PARTICIPANT_LIVELINESS_QOS at a rate faster than the smallest lease duration among these Writers. The two instances are orthogonal in purpose so that if a Participant contains Writers of each of the two liveliness kinds described, two separate instances must be periodically written. The instances are distinguished using their DDS key which is comprised of the participantGuidPrefix and the kind fields. Each of the two types of liveliness QoS handled through this protocol will result in a unique kind field and therefore form two distinct instances in the HistoryCache.

In both liveliness cases the participantGuidPrefix field contains the GuidPrefix_t of the Participant that is writing the data (and therefore asserting the liveliness of its Writers).

The DDS liveliness kind MANUAL_BY_TOPIC_LIVELINESS_QOS is not implemented using the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader. It is discussed in Section 8.7.2.2.3.

· Add the following entries to Table 9.2

BuiltinParticipantMessageWriter ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER =

BuiltinParticipantMessageReader ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER =

· Insert a new Section 9.6.2.1 with the following content:

9.6.2.1 Data representation for the ParticipantMessageData built-in Endpoints
The Behavior Module within the PIM (Section 8.4) defines the DataType ParticipantMessageData. This type is the logical content of the BuiltinParticipantMessageWriter and BuiltinParticipantMessageReader built-in Endpoints.

The PSM maps the ParticipantMessageData type into the following IDL:

struct ParticipantMessageData

;

The DDS key consists of the both the participantGuidPrefix and the kind fields. On the wire, the participantGuidPrefix and the kind are not serialized as part of the ParticipantMessageData because they are already explicitly serialized as part of the Data Submessage (see Section 8.3.7.2).

The following values for the kind field are reserved by RTPS:

#define PARTICIPANT_MESSAGE_DATA_KIND_UNKNOWN

#define PARTICIPANT_MESSAGE_DATA_KIND_AUTOMATIC_LIVELINESS_UPDATE

#define PARTICIPANT_MESSAGE_DATA_KIND_MANUAL_LIVELINESS_UPDATE

RTPS also reserves for future use all values of the kind field where the most significant bit is not set. Therefore:

kind.value[0] & 0x80 == 0 // reserved by RTPS
kind.value[0] & 0x80 == 1 // vendor specific kind

Implementations can decide the upper length of the data field but must be able to support at least 128 bytes.

Following the CDR encoding, the wire representation of the ParticipantMessageData structure is:

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

------------------------------------------------------+

~ octet[] data.value ~

------------------------------------------------------+

· Insert a new Section called 9.6.2.2
Use the contents of Section 9.6.2 from the start until the beginning of Section 9.6.2.1

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
(NOKEY_)DATA_FRAG PSM submessage definition should be modified to place inlineQos AFTER fragmentation related parameters to simplify an implementation based on gather send.
Resolution:
Reposition the inlineQos field to be consistent with other messages, implementation simplicity, and higher performance.
Revised Text:
· Section 9.4.5.4, change
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

+ SequenceNumber writerSN +

------------------------------------------------------+

~ ParameterList inlineQos [only if Q==1] ~

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

~ SerializedData serializedData ~

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

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

+ SequenceNumber writerSN +

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

~ ParameterList inlineQos [only if Q==1] ~

------------------------------------------------------+

~ SerializedData serializedData ~

------------------------------------------------------+

· Section 9.4.5.6, change
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

+ SequenceNumber writerSN +

------------------------------------------------------+

+ +

+ +

------------------------------------------------------+

------------------------------------------------------+

~ ParameterList inlineQos [only if Q==1] ~

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

~ SerializedData serializedData ~

------------------------------------------------------+

to

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

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

+ SequenceNumber writerSN +

------------------------------------------------------+

+ +

+ +

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

------------------------------------------------------+

~ ParameterList inlineQos [only if Q==1] ~

------------------------------------------------------+

~ SerializedData serializedData ~

------------------------------------------------------+

see below

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Encapsulation of serialized data should be the responsibility of the plug-in. Even though the protocol does not need to interpret the data stream, in the case of fragmented data, the data encapsulation header need only be pre-pended to the first fragment. Further fragments don't need the encapsulation header.
Resolution:
Add a new SubmessageElement subclass called SerializedDataFragment.

Revised Text:

Renumber 8.3.5.15 (StatusInfo) to 8.3.5.16, and add new section 8.3.5.15

8.3.5.15 SerializedDataFragment

SerializedDataFragment contains the serialized representation of a the value of a data-object that has been fragmented. Like for unfragmented SerializedData, the RTPS protocol does not interpret the fragmented serialized data-stream. Therefore, it is represented as opaque data. For additional information on data encapsulation, see Chapter 10.

Add table 8.32 - Structure of the SerializedDataFragment SubmessageElement
field type meaning
value octet[*] Serialized data-stream fragment

Replace Figure 8.12 with :

for updated figure see page 27 of ptc/2007-06-02

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The extensions made to the protocol break backwards compatibility and therefore the major version should be changed not the minor version.
Resolution:
Change the version number from 1.2 to 2.0.
Revised Text:
Change "1.2" to "2.0" in the following locations:
· Table 8.13, 5th row (first cell reads "SubmessageKind"), the cell in the second column
· Section 8.3.3.1.2, first paragraph, first sentence.
· Section 8.3.4.1, numbered item 3, second sentence

· Section 8.3.4.1, numbered item 4, third sentence.
· Section 8.3.5, first paragraph, second sentence
· Section 8.3.5.3, second paragraph (right after Table 8.20), first sentence
· Section 8.3.5.9, within the bulleted items following the second paragraph
o the second sentence in the second bulleted item
o the second sentence in the third bulleted item
· Section 8.3.7, first paragraph, first sentence
· Section 8.6, first paragraph, first sentence
· Section 9.3.1.2, last paragraph (right before Table 9.1), second sentence
· Section 9.3.1.4, the title
· Section 9.3.1.4, first paragraph, first and second sentences
· Table 9.3, the caption
· Section 9.4.2.11, last paragraph, first (and only) sentence
· Section 9.4.5.1.1, first paragraph, last sentence
· Section 9.4.5.1.2, last paragraph, first and second sentences
· Section 9.6.4, the title
· Section 9.6.4, first paragraph, first and second sentences

Other changes:
· Table 8.2, 6th row (cell in first column reads "ProtocolVersion_t"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
o NOTE: there are two instances of this change in this cell.
· Table 8.16, 2nd row (cell in first column reads "sourceVersion"), the cell in the second column, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
· Section 8.3.3.1.2, change "(major = 1, minor = 2)" to "(major = 2, minor = 0)"
· Section 8.3.5.3, second paragraph, within the list of special values, change "PROTOCOLVERSION_1_2" to "PROTOCOLVERSION_2_0"
· Section 8.6, first paragraph, first sentence, change "(1)" to "(2)"
· Section 9.3.1.2, last paragraph (right before Table 9.1), third sentence, change "(1)" to "(2)"
· Table 9.4, 5th row (first cell contains "ProtocolVersion_t")
change:

#define PROTOCOLVERSION_1_2

to:

#define PROTOCOLVERSION_2_0

also, in the last sentence, change "version 1.2 (major = 1, minor = 2)" to "version 2.0 (major = 2, minor = 0)"
· Section 8.3.3.1, last paragraph, first (and only) sentence, change "(1)" to "(2)"
· Section 8.3.3.2, last paragraph (following Table 8.15), first (and only) sentence, change "(1)" to "(2)"
· Section 8.3.3.2.1, second paragraph, first sentence, change "(1)" to "(2)"
· Section 9.3.1.3, second paragraph, third sentence, change "(1)" to "(2)"
· Section 9.4.4, second paragraph, change "(1)" to "(2)"
· Section 9.4.5.1, second to last paragraph, first (and only) sentence, change "(1)" to "(2)"
· Section 9.4.5.1.1, second paragraph, first sentence, change "(1)" to "(2)"

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The protocol should clarify the sequence number of a writer's first sample. Currently, this is not specified in 8.3.5.4. Rather, it is implied by 8.3.5.5 which states that a sequence number set contains sequence numbers >= 1. The same issue applies for a fragment number.
Resolution:
Explicitly state that the sequence number of a writer's first sample or fragment is 1.
Revised Text:
· Section 8.3.5.4, first paragraph, append text

Sequence numbers begin at 1.

· Section 8.3.5.6, first paragraph, append text

Fragment numbers begin at 1.

No Data Available

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
For out-of-the-box interoperability, we should provide default timing parameters for the reliability protocol.
Resolution:
Provide default timing parameters for the reliability protocol.
Revised Text:
· Add a new Section 8.4.7.1.1 titled "Default Timing-RelatedValues" with the following content:

The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
nackResponseDelay.sec = 0;
nackResponseDelay.nanosec = 200 * 1000 * 1000; // 200 milliseconds
nackSuppressionDuration.sec = 0;
nackSuppressionDuration.nanosec = 0;

· Add a new Section 8.4.10.1.1 title "Default Timing-Related Values" with the following content (NOTE: heartbeatSuppressionDuration does not currently exist in RTPS but is added through issue R#7) :

The following timing-related values are used as the defaults in order to facilitate 'out-of-the-box' interoperability between implementations.
heartbeatResponseDelay.sec = 0;
heartbeatResponseDelay.nanosec = 500 * 1000 * 1000; // 500 milliseconds
heartbeatSuppressionDuration.sec = 0;
heartbeatSuppressionDuration.nanosec = 0;

No Data Available

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
In order to implement the DDS DURABILITY Persistent QoS, a persistence-service needs to send the data that has been received and stored on behalf of the persistent writer.

The service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

Resolution:
Introduce a new parameter Id, ORIGINAL_WRITER_INFO, that can appear in parameter lists.

Revised Text:

Add to table 9.4:

Type PSM Mapping
OriginalWriterInfo_t struct

OriginalWriterInfo;

Append to table 9.13:
Name ID Type
PID_ORIGINAL_WRITER_INFO 0x0061 OriginalWriterInfo_t

Add new section:

8.7.6 Original Writer Info

A service supporting the Persistent level of DDS Durability QoS needs to send the data that has been received and stored on behalf of the persistent writer.

This service that forwards messages needs to indicate that the forwarded message belongs to the message-stream of another writer, such that if the reader receives the same messages from another source (for example, another forwarding service or the original writer), it can treat them as duplicates.

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

OriginalWriterInfo_t
attribute type value
originalWriterGUID GUID_t the GUID of the RTPS Writer that first generated the message
originalWriterSN SequenceNumber_t the Sequence Number of the CacheChange as sent from the original writer
originalWriterQos ParameterList the list of inline parameters that should apply to the CacheChange as sent by the RTPS Writer that first generated the sample

When a RTPS reader receives this information it will treat it as a normal CacheChange, but once the CacheChange is ready to be commited to the DDS DataReader, it will not commit it. Instead, it will hand it off to the HistoryCache of the RTPSReader that is communicating with the RTPSWriter indicated in the ORIGINAL_WRITER_INFO inline-Qos and treat it as having the sequence number which appears there and the ParameterList also included in the ORIGINAL_WRITER_INFO.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Table 8.5 incorrectly shows a ChangeKind_t as having no applicable relation to DDS. Rather, the instance state kind of being disposed and unregistered are related to ChangeKind_t.

Resolution:
Revise table 8.5 to show the relationship between CacheChange kind and DDS instance state kind.

Revised Text:
Revise table 8.5:
Attribute Type Meaning Relation to DDS
kind ChangeKind_t Identifies the kind of change. See Table 8.2 DDS instance state kind

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Clarify that GAPs should be used only when a sample is not meaningful and not sent in the first place (e.g. filtered out).
Resolution:
Clarify GAP usage.

Revised Text:
Revise 8.3.7.4.5:

The RTPS Writer sends the Gap message to the RTPS Reader to communicate that certain sequence numbers are no longer relevant. This is typically caused by the KEEP_LAST setting of the History QoS on the corresponding DDS DataWriter. This is typically caused by Writer-side filtering of the sample (content-filtered topics, time-based filtering). In this scenario, new data-values may replace the old values of the data-objects that were represented by the sequence numbers that appear as irrelevant in the GAP.

see above

Summary:
Table 9.13 in section 9.6.3 contains a parameter called PID_TOPIC_NAME as one of the in-line QoS settings. This parameter is not mentioned in the PIM.
Resolution:
First extend section 8.7.1 explaining the rationale behind in-line QoS data. This is addressed in OMG issue #11050 already. Then add the TOPICNAME parameter in section 8.7.2.1.
Revised Text:
· Section 8.7.2.1, add the following sentence :
In-line parameters are added to data sub-messages to make them self-describing. In order to achieve self-describing sub-messages, not only the parameters defined in table 8.7.2.1 have to be sent with the sub-message, but also a parameter TOPICNAME. This parameter contains the name of the topic that the sub-message belongs to.

see below

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The RTPS specification state which QoS can appear in-line but does not offer background information to justify their usage. The specification should elaborate on how in-line QoS are required for stateless implementations.

Resolution:
Elaborate on necessities and justifications for having in-line QoS to support stateless implementations.

Revised Text:
Revise 8.7.1, insert starting as third paragraph:

A stateless Reader's need for receiving in-line QoS to get information on remote Writers is the justification for requiring a writer to send in-line QoS if the reader requests them (section 8.4.2.2.2).

For immutable QoS, all RxO QoS are sent in-line to allow a stateless reader to reject samples in case of incompatible QoS. Mutable QoS relevant to the reader are sent in-line so they may take effect immediately, regardless of the amount of state kept on the reader. Note that a stateful reader has the option of relying on its cached information of remote writers rather than received in-line QoS.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Data encapsulation for Serialized Data Fragments needs differentiation from data encapsulation of serialized data. Fragmentation should be done after encapsulation of large serialized data. Rather than having an encapsulation header for each fragment, only a single encapsulation header is needed, as this is used after the sample has been reconstituted from its fragments. The specification of data encapsulation schemes should describe this.

Also, in Sections 10.1.1-2, the length field of the data encapsulation schemes shown in the submessage diagrams are unnecessary, because the serialized data and fragments already contain sufficient information to determine the length of data. Instead, the field should be designated for data encapsulation scheme-specific options.
Resolution:
Replace the length field of the standard data encapsulation schemes with a scheme-specific option field.

Define fragmentation as happening after encapsulation of a large data sample.

Revised Text:
· Section 10.1.1.2
WAS
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

~ Serialized Data (CDR Big Endian) ~

------------------------------------------------------+

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

------------------------------------------------------+

~ Serialized Data (CDR Little Endian) ~

------------------------------------------------------+

NOW:
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

~ Serialized Data (CDR Big Endian) ~

------------------------------------------------------+
Fragmentation is done after encapsulation of large serialized data.

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

------------------------------------------------------+

~ Serialized Data (CDR Little Endian) ~

------------------------------------------------------+

· Section 10.1.1.3
WAS:
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

~ Serialized Data (ParameterList CDR Big Endian) ~

------------------------------------------------------+

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

------------------------------------------------------+

~ Serialized Data (ParameterList CDR Little Endian) ~

------------------------------------------------------+

NOW:
0...2...........8...............16..............24..............32
+

------------------------------------------------------+

~ Serialized Data (ParameterList CDR Big Endian) ~

------------------------------------------------------+

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

------------------------------------------------------+

~ Serialized Data (ParameterList CDR Little Endian) ~

------------------------------------------------------+

Fragmentation is done after encapsulation of large serialized data, so a SerializedDataFragment may contain the encapsulation header of its larger opaque SerializedData sample.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The use of the count submessage element is not fully explained.

For heartbeats, the Count element differentiates logical heartbeats, so heartbeats with the same count as a previously received heartbeat can be ignored to prevent triggering duplicate repair sessions. Also, old heartbeats with count less than previously received counts should also be ignored. So, same logical heartbeats must not have the same count, and new heartbeats must have greater counts than older heartbeats.

The same logic applies to counts of ACKNACKs.

Resolution:
Explain proper usage of the count element of Heartbeats and ACKNACKs.

Revised Text:
Add new section:

8.4.14.6 Setting Count of Heartbeats and ACKNACKs
The count element of Heartbeats differentiates logical heartbeats. A received heartbeat with the same count as a previously received heartbeat can be ignored to prevent triggering a duplicate repair seesion. So, an implementation should ensure same logical heartbeats are tagged with the same count.

Also, new heartbeats should have counts greater than all older heartbeats. Then, received heartbeats with counts less than or equal to any previously received can be ignored.

The same logic applies for counts of ACKNACKs: each logical ACKNACK

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The specification should describe how finite resources impact reliable communications.

Writer queue resources should be reclaimed when no remote reader needs the corresponding sample. This means at least samples that have been fully acknowledged may be reclaimed. However they may exist unresponsive readers that are alive but for some reason never acknowledge the writer. To enable a writer to reclaim resources in this case, we define the notion of inactive Readers. If a reader is detected to be unresponsive through some mechanism (for example, when not responding to successive Heartbeats), the reader is deemed inactive. Then, samples that have been fully acknowledged by all active readers may be reclaimed. The writer should continue sending new samples and Heartbeats to inactive readers, but the writer need not hold onto old samples that were not acknowledged by inactive readers. The specification must note that strict reliability is no longer guaranteed when a reader becomes inactive.

Resolution:
Explain reliability in the presence of finite resources. Introduce and describe "isActive" reader attribute.

Revised Text:
Add new section
8.4.14.6 Reclaiming Finite Resources from Unresponsive Readers

An implementation likely has finite resources to work with. For a writer, reclaiming queue resources should happen when all readers have acknowledged a sample in the queue and resource limits dictate that the old sample entry is to be used for a new sample.

There may be scenarios where an alive reader becomes unresponsive and will never acknowledge the writer. Instead of blocking on the unresponsive reader, the writer should be allowed to deem the reader as 'Inactive' and proceed in updating its queue. The state of a reader is either Active or Inactive. Active readers have sent ACKNACKs that have been recently received. The writer should determine the inactivity of a reader by using a mechanism based on the rate and number of ACKNACKs received. Then samples that have been acknowledged by all active readers can be freed, and the writer can reclaim those resources if necessary. Note that strict reliability is not guaranteed when a reader becomes inactive.

Add to table 8.59 - RTPS ReaderProxy Attributes
Attribute Type Meaning Relation to DDS
isActive bool Specifies whether the remote reader is responsive to the writer. N/A

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Stateful readers should be allowed to rely on cached information propagated by discovery of remote writers. Thus, support for receiving and parsing inline QoS should be optional for stateful readers.

In the case of mutable QoS, a tradeoff happens, where not parsing these inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery. A stateful implementation may expose this tradeoff to the user: minimize bandwidth usage by not sending mutated inline QoS or avoid this delayed effect of certain mutable QoS for guaranteed semantics.

Resolution:
Allow stateful implementations the choice of whether or not to parse inline QoS.

Revised Text:
Add as last paragraph of 8.7.1:

Stateful implementations can ignore inline QoS and rely solely on cached values obtained through discovery in order to improve performance. Note that not parsing inline QoS may delay the point in time when a new QoS takes effect, as it first must be propagated through discovery

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
A directed write feature for tagging a sample with the GUID of the sample's single intended recipient must be supported with a new parameter Id to allow the GUID to be serialized as an inline parameter.

Resolution:
Add a new standard parameter Id, PID_DIRECTED_WRITE, with ID of 0x0057 and type of a sequence of GUIDs.

Revised Text:
Add following section:

8.7.6 Directed Write
Direct peer-to-peer communications may be enabled within the publish-subscribe framework of DDS by tagging samples with the handles of the intended recipient(s).

RTPS supports directed writes by using the inline QoS parameter extension mechanism. The serialized information denotes the GUIDs of the targeted readers.

When a writer sends such a directed sample, only the recipients with the matching parsed GUIDs accept the sample; all others acknowledge but absorb the sample, as if it was a GAP indicating a filtered sample.

Append to Table 9.13:
Name ID Type
PID_DIRECTED_WRITE 0x0057 sequence<GUID_t>

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
Resolution:
Allow Writer to reclaim resources and send repairs if possible.
Revised Text:
Add the paragraph to the end of Section 8.4.2.3.3:

Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Requirement 8.4.2.3.4 currently states "Readers can only send an ACKNACK Message in response to a HEARTBEAT message." This implies a reader may not poll for samples by unilaterally NACKing. This is true in general: the frequency and bandwidth of NACKs and associated repair messages is well maintained if controlled only by the writer. However, in the case when a Reader first finds out about a remote writer, before it receives any heartbeats, it may optionally send an ACKNACK to notify the writer. This can expedite communications between the new writer/reader pair, as the arrival time of the first heartbeat may be indeterminate.

The rationale of writer-only control of NACK and associated repair messages should be incThis optimization should be noted within an implementation note.

Resolution:
Clarify requirement 8.4.2.3.4 to include the special case of a Reader first discovering a Writer.
Revised Text:
· Change the text of Section 8.4.2.3.4 to:

In steady state, an ACKNACK Message can only be sent as a response to a HEARTBEAT Message from a Writer. ACKNACK Messages can be sent from a Reader when it first discovers a Writer as an optimization. Writers are not required to respond to these pre-emptive ACKNACK Messages.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

Resolution:
A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

Revised Text:
Append to 8.4.2.3.2:

The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

Revise statechart 8.24:

Revise Table 8.76 with revised transition:

Transition state event next state
T2 waiting HEARTBEAT message is received if (HB.FinalFlag==NOT_SET)then must_send_ackelse if (HB.LivelinessFlag == NOT_SET)then may_send_ackelse waiting

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Requirement 8.4.2.2.4 should be clarified: a writer does not only respond with data or a GAP as stated. Rather, since a writer may have KEEP_LAST semantics and so may not offer the requested sample anymore, it may also respond with a new HB indicating the requested sample is no longer available. This is the mechanism to trigger a reader's onDataLost callback.

Resolution:
Clarify 8.4.2.2.4 to include a Writer's response of a HB to an ACKNACK requesting a sample that the writer does not have available.

Revised Text:
Revise first paragraph of 8.4.2.2.4:
When receiving an ACKNACK Message indicating a Reader is missing some data samples, the Writer must respond by either sending the missing data samples, sending a GAP when the sample is not relevant, or sending a Heartbeat when the sample is no longer available.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
A type's maximum serialized size may be included in a parameter list. A new parameter Id should be added.

Resolution:
Add parameter Id for Type Max Sample Size Serialized

Revised Text:

Append to Table 9.11:
Name ID Type
PID_TYPE_MAX_SIZE_SERIALIZED 0x0060 long

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
User definable name-value pairs can serve as a generic and extensible framework for DDS properties. These properties may be serialized in parameter lists and thus need a corresponding unique parameter Id.
Resolution:
Add parameter Id for Property List.
Revised Text:
Add section:

8.7.5 Property Lists

Property lists are lists of user-definable properties applied to a DDS Entity. An entry in the list is a generic name-value pair. A user defines a pair to be a property for a DDS Participant, DataWriter, or DataReader. This extensible list enables non-DDS specified properties to be applied.

The RTPS protocol supports Property lists as inline parameters. Properties can then be propagated during discovery or as inline QoS.

Append to Table 9.4:

Type PSM Mapping
Property_t struct

Property_t

Append to Table 9.11
Name ID Type
PID_PROPERTY_LIST 0x0059 sequence<Property_t>

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
Currently, the specification does not state whether a multicast DataReader must also have a unicast locator or not.
Resolution:
A unicast locator should be supplied for multicast DataReaders so that repair sessions can be sent over unicast. If one is not provided directly, then the Participant's locator can be assumed.

Revised Text:
Revise following entry in Table 8.77 - RTPS SPDPdiscoveredParticipantData attributes:

attribute type meaning
defaultUnicastLocatorList Locator_t[1..*] Default list of unicast locators (transport, address, port combinations) that can be used to send messages to the user-defined Endpoints contained in the Participant.These are the unicast locators that will be used in case the Endpoint does not specify its own set of Locators, so at least one Locator must be present.

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

Resolution:
Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

Revised Text:
Revised figure 8.21:

Revised table 8.66

Attribute Type Meaning Relation to DDS
heartbeatSuppressionDuration Duration_t Protocol tuning parameter that allows the RTPS Reader to ignore heartbeats that arrive 'too soon' after a previous heartbeat was received. N/A

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
Resolution:
Add parameter Id for Entity Name.
Revised Text:

Type PSM Mapping
EntityName_t struct

EntityName_t

Append to Table 9.11:
Name ID Type
PID_ENTITY_NAME 0x0058 EntityName_t

see above

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
A DDS entity name could be serialized within a parameter list, so a corresponding unique parameter Id should be assigned.
Resolution:
Add parameter Id for Entity Name.
Revised Text:

Type PSM Mapping
EntityName_t struct

EntityName_t

Append to Table 9.11:
Name ID Type
PID_ENTITY_NAME 0x0062 EntityName_t

This issue was already resolved the suggested changes are already in the spec.
Revised Text:
Disposition: NoChange

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
For better performance and simpler reliability, a liveliness heartbeat should be allowed to be a liveliness-only message without heartbeat semantics. As subclassed from a heartbeat, a liveliness heartbeat may trigger an ACKNACK response; to be a liveliness-only message, no ACKNACKs should be triggered. To enable this, setting the final flag should not trigger ACKNACKs.

Resolution:
A liveliness heartbeat with final-flag set must not trigger any ACKNACKs.

Revised Text:
Append to 8.4.2.3.2:

The response is not required when a liveliness HEARTBEAT has both liveliness and final flags set to indicate it is a liveliness-only message.

Revise statechart 8.24:

This issue was already resolved as part of the FTF, in that report it is labeled as
issue 11043. It appears that a typographical mistake was made in the report (or else
something changed in the database) so that the issue was not closed in the OMG
database.
Revised Text:
Disposition: NoChange

Source:
Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The specification does not prevent multiple Heartbeats from arriving in rapid succession. For example, the piggyback heartbeat of a repair message may immediately be followed by a periodic wildcard heartbeat. In order to prevent duplicate repair sessions, the specification should define heartbeat suppression on the reader's side. This heartbeat response suppression should be handled by a reader attribute that controls the duration for which duplicate heartbeats would be ignored.

Resolution:
Add reader attribute, heartbeatSuppressionDuration, that defines the duration in which received heartbeats are suppressed from triggering duplicate ACKNACKs.

Revised Text:
Revised figure 8.21:

This issue was already resolved as part of the FTF, in that report it is labeled as
issue 11041. It appears that a typographical mistake was made in the report (or else
something changed in the database) so that the issue was not closed in the OMG
database.
Revised Text:
Disposition: NoChange

Real-Time Innovations, Inc. (Ken Brophy, ken@rti.com)
Summary:
The requirement contained in Section 8.4.2.3.3 is too restrictive and doesn't specify when resources can be reclaimed. If all Readers have acknowledged a sample, the Writer should be allowed to reclaim that sample's resources. Also, if a Reader NACKs a sample it has already ACKed, and the Writer is still able to provide a repair, it should.
Resolution:
Allow Writer to reclaim resources and send repairs if possible.
Revised Text:
Add the paragraph to the end of Section 8.4.2.3.3:

Once a Writer has received positive acknowledgement from all Readers, the Writer can reclaim any associated resources. However, if a Writer receives a negative acknowledgement to a previously positively acknowledged sample, and the Writer can still service the request, the Writer should send the sample.

This issue was already resolved as part of the FTF, in that report it is labeled as
issue 11037. It appears that a typographical mistake was made in the report (or else
something changed in the database) so that the issue was not closed in the OMG
database.