Thank you, Andrew.
So, what are you saying -- you do not expect that we would face major problems if we use QNET-over-IP?

We, like vast majority of QNX customers, were using QNX-over-Ethernet for years. This was a logical choice for the 
network configuration we had in the previous products -- single (as seen by the Networking Stack and the Application 
code) network interface on top of which both TCP/IP and QNET were riding. The Networking driver was modified to perform 
link switching between multiple NICs. Thus, for any software, which was running above the driver, there was only one 
physical link. All others were hidden and disabled by the driver.

In the last product (for certain reasons) we are using different configuration -- redundant and all active links. The 
problem with this -- when we are using two different transports (TCP/IP and QNET), they require different mechanism of 
link switching and synchronization. TCP/IP is sitting on different subnets (one subnet per physical link) and switching 
is performed by applying the third (virtual) subnet (in form of IP alias) to one of the underlying subnets. QNET, from 
the other hands, uses a link grouping. My experiments showed that even though QNET suppose to do load balancing over all
 available links, it operates only with one of them at a time. When that link fails, it requires some time (20 seconds 
or something) to detect this failure and switch to the different link. Thus, there are time windows when both TCP/IP and
 QNET transport may not be in sync (even if timeout is reduced). The logical solution for this problem (as I see it) -- 
to use QNET-over-IP. This allows to treat QNET as a "regular" Stack User, thus if we monitor and deal with IP link 
failures, the problem with QNET is resolved automatically.

Of course, we could monitor and switch IP and QNET independently (that was the original plan). But, this doesn't seem as
 a neat solution.