Enabling FastRTPS' ThroughputController

[dhood]

This was originally discussed in #36
It can be enabled by un-commenting these lines

Motivation:

• Enhance performance for sending large messages with "best effort" reliability (otherwise all message fragments are sent at the same time, something happens (yet to be determined what) that prevents data from being received, and as it's best effort the fragments are not resent)

Reasons against:

• This can limit the throughput of systems.

Options:

1. Enable only if best effort is being used. If users want higher throughput than the controller they will have to use reliable reliability.
2. Enable always and accept the limited throughput.
3. Expose a flow controller QoS setting, as it's also available in Connext see this page
4. Expose the appropriate symbols to the user so that they can set the throughput controller themselves.

If we decide to go for 1 or 2, it may be useful to know that for the image_tools demo sending 320x240 @30fps we send ~8million bytes per second. A throughput controller of ~30,000 bytes/10ms (3million/s) is sufficient.

[dhood]

Thanks @mikaelarguedas for pointing out that implementing the throughput controller by un-commenting these lines will apply the same controller to all topics which will not be sufficient for cases where you need different controllers for different topics.

[mikaelarguedas]

@dhood do you think that this can be closed in favor of ros2/rmw#115 ?

[sloretz]

I removed more-information-needed because it seemed to be added in reference to ros2/rmw#115 which itself was closed in favor of more specific tickets, so this ticket shouldn't be closed in favor of that one.

It seems like the milestone for this could be untargeted - it is desirable but no one appears to be advocating for it to be resolve anytime soon.

[dirk-thomas]

I changed the milestone to Bouncy since I think it is crucial to fix the performance problem we are facing in e.g. the image demos with FastRTPS in the past releases.

[mikaelarguedas]

With #202 (and this commit eProsima/Fast-DDS@201a393) it looks llike the performace issues we were facing with Fast-RTPS have been resolved. As the performance is now similar to the other RMW implementations I'm going to close this issue

[paulbovbel]

Just to verify since ros2/rmw#115 is closed as well, does this mean QoS settings for flow control will not be exposed via RMW?