I am one of the authors of the paper and I can give some more details about ZMQ.

- The objective of our paper was to look into scalability issues for typical publish/subscribe systems. We did not modified roscpp and we used a plain ZMQ stack and the roscpp stack.

- IMO the major advantage of ZMQ is the ability to build highly-efficient systems with a combination of different ZMQ sockets such as broker, queue, dealer and router and a combination of thereof. However, to construct such highly-efficient applications demands detailed knowledge about the topology
"and deployment setting (inproc, inter-proc, WAN, LAN,..). I am not sure how to generalize this in a new transport layer for ROS. But that's maybe a great challenge for this SIG :)

In the spirit of the new dependency-choice philosophy of ROS 2.0 I think
zmq is a really good choice because (a) it does what we would want ROS to
do, and (b) it's supported by a commercial entity [5]. If someone had time
to prototype a modification to roscpp in ros_comm as well as the master to
allow for zmq-based TCP/UDP/PGM (multicast) without changing the current
ROS API, that would be really cool. Fundamentally, it would work the same
as the current ROS networking architecture, which means we'd also be able
to compare performance to the current implementation.

I am really curious about ROS 2.0. However, I do not have any detailed information about it. Is there any material available?..Sigh..I missed
ROSCON.