Subscriber-side throttling

[ciandonovan]

Describe the feature

DDS is so problematic over WiFi that even for working on the robot in our lab sitting just meters away, we use a Zenoh bridge to communicate.

We have a fairly unconstrained configuration, only limiting uncompressed image/video topics, with 150 mbps being the norm for bandwidth downstream from the robot.

This works quite well, until someone remotely needs to bridge into the robot (WFH etc.) We could use a different more conservative configuration, drastically throttling all high-bandwidth topics, but this unnecessarily degrades the experience of those adjacent the robot.

I've tried running multiple bridges on different ports, the idea that each would have a different configuration, with different rates of throttling, that a remote user could choose which to connect to based on their circumstance. But this seems to cause a weird issue where frames are duplicated slightly out of timesync and sent together, presenting on the video feeds as rewinding and fastforwarding type glitches.

Ideally, a remote client/subscriber could inform the Zenoh bridge/server how to throttle the publishing of the topics, but for that client/subscriber alone, instead of a single global setting. This would be much more flexible and allow much greater granularity, as well as reducing overhead compared to running multiple bridges.

[JEnoch]

I've tried running multiple bridges on different ports, the idea that each would have a different configuration, with different rates of throttling, that a remote user could choose which to connect to based on their circumstance. But this seems to cause a weird issue where frames are duplicated slightly out of timesync and sent together, presenting on the video feeds as rewinding and fastforwarding type glitches.

Running 2 bridges on a same ROS_DOMAIN_ID is no a good idea, since they will discover each other and each one will route the DDS traffic published by the other.
To avoid this, I shall probably add a deny.nodes configuration that will avoid 2 bridges to route each other. I created #65 for this.

Ideally, a remote client/subscriber could inform the Zenoh bridge/server how to throttle the publishing of the topics, but for that client/subscriber alone, instead of a single global setting. This would be much more flexible and allow much greater granularity, as well as reducing overhead compared to running multiple bridges.

Agreed, but this must be implemented in the Zenoh routing engine (used by zenohd and any Zenoh peer, not by a Zenoh client which has only 1 connection anyway).
We're working on this (eclipse-zenoh/zenoh#660) and it will hopefully come soon. Note that it will be managed by configuration of the bridge or router, rather than by the subscriber declaring its wish.