It looks like I started something of a minor storm moments before starting a holiday…
I’m thankful that the DDS vendors, PrismTech, RTI, Twin Oaks and eProsima, are all engaged enough in the ROS community to be present on the Discourse board. It is encouraging to future adopters of ROS 2.
I wasn’t implying religious believe. It’s an simply expression to describe someone making an assertion. 
I fully agree that PrismTech’s submission has much smaller messages than the RTI/Twin Oaks/eProsima submission based on the two presentations alone.
While this is true, the other submission has managed to define an object model as well, and in addition kept it close to the existing DDS one.
It is quite common to use flags. TCP is full of them. My concern is that the protocol is, in my opinion, undoubtedly complex and, based solely on the presentations, more complex than the other submission. Complexity and size are often a balance and in this situation we appear to have one submission at each end of the balance.
With the sorts of overhead you are achieving, I’m not surprised performance is amazing. I’d still like to see numbers, though.
As was stated elsewhere in this thread, eProsima’s implementation wasn’t optimised. Since you said you are trying to bring yours to market already and eProsima claimed theirs was a tech demo, I’m not surprised yours is more optimised and thus smaller. Of course, the numbers are definitely in your favour for RAM usage. But I’m curious how much program memory each implementation requires, too. This is often the limiting factor on embedded microprocessors rather than the RAM usage.
I didn’t catch that even once during the presentation. Next time, put such an important motivating factor in your slides. 
RTI and co were much better at motivating their design decisions, and that put a positive spin on their submission.
You probably also should have put that requirement in the RFP, if it’s that important. The other submission cannot aim for a requirement they are not aware of.
Since the submissions have not gone to the AB yet, as far as I know, then there should not be any official AB reviews, which suggests to me that RTI asked for unofficial reviews from AB members. This may be why they are not public?
In that case I am very interested in seeing what these AB members wrote.
That may have been RTI’s reason, but the reason the rest of us present voted no is because we still have two vastly different submissions with no apparent readiness to work towards a single one. PrismTech even behaved in their presentation as if they are expecting RTI, Twin Oaks and eProsima to through away their submission and go with PrismTech’s.
“Cutting down”, not “cutting out”. I meant that you are trying to reduce the size of the messages on the wire as much as possible, at the expense of possibly needing more complex parsing code. I didn’t mean to say that you are cutting out features. It was clear from the presentation that PrismTech supports more features and has more flexibility than the other submission. But there are trade-offs involved.
Neither of these are required by the RFP. The RFP heavily directs the submitter towards the style of architecture that RTI/Twin Oaks/eProsima provided.
Yes, this is something that I was disappointed about. Hearing RTI’s presentation talk about TCP/IP only seemed to rule out using it on things like Zigbee. But on the other hand, perhaps it’s readily adaptable?
Well, it is DDS-XRCE, is it not?
It was very useful. I wish I had had this information during the presentation. I still have not had time to read the submissions in detail and unfortunately will not be able to do so before November, but fortunately we now have until February next year to try and resolve this situation.
And, as @vmayoral said, having code available would make a difference to how well we can judge things like implementation complexity.
While this is true, we are operating at a standardisation organisation, not a rubber stamp provider. There are interested parties beyond just the implementers. We would prefer not to just hold a vote on which submission to go forward with. We would prefer the submitters to actually work together and produce a single submission that combines the best of both without any technological compromises (yes, I’m aware how hard that is).
Or, you could provide the answers to those questions, along with the equivalent answers for your submission, so we can see and compare the data to back up your claims.
This is the strongest impression I got from the presentation, as I said in my own notes. The data model is similar to DDS, which makes adoption by existing DDS users easier, and the ability to implement the protocol in a relatively simple piece of code (which makes it easier to verify and certify) was considered as important as saving bytes on the wire. I’m not sure where the correct balance is between these two requirements, but the PrismTech implementation really gave the impression of being at one extreme.
This is something that I think is really relevant but that PrismTech have not addressed at all, and RTI/Twin Oaks/eProsima have not addressed enough. What are the typical microcontrollers in use today? What are the target environments for this protocol to be used in?
The RFP explicitly says this:
Both submissions fit within both the RAM usage (with much room to spare) and the protocol overhead.
More specifically, the actual mandatory requirement is:
Again, this should have been in the RFP if it is so important. That would have saved a lot of trouble. All we got was an evaluation criteria:
This is a miserably small set of criteria for a complex design space. Even you, @eboasson, say that protocol overhead is not as important as the design philosophy.
Which I agree is fundamentally different between the two proposals, and that this is where the root cause lies in the failure to reconcile them.
The RFP not-so-subtly pushes submitters in this direction. You cannot fault them for taking it at face value.
I will read both submissions and when I do, I will report back with more technically-informed comments.