Tcp – Redundant IP link aggregation for failover operation without route failure detection

Architecturefailoverpacket-lossredundancytcp

I am looking for a technology to achieve TCP connection fault tolerance with the help of two links between hosts and without time delays for route failure detection. Something like this:

                       link1   packet1copy1->
                     --------------------------
      packet1->     /                          \    packet1copy1/packet1copy2->
host1--------router1                            router2 ------------------------host2
                    \  link2   packet1copy2->  /
                     --------------------------

host1 and host2 are connected via router1 and router2 with two links between them. Each router duplicates every packet coming from hosts before forwarding them into both links simultaneously. Then either the peer router or the destination host IP stack take care of redundant packet elimination.

Edit:
This is in fact a search for a general purpose fault-tolerance-by-replication solution for TCP (IP) transport. The solution should be of no-need-to-recover type as opposed to reasonably-fast-to-recover approaches like BGP / OSPF / Cisco IP SLA, etc. Some proprietary packet redundancy solutions are known already, though insufficiently universal. In particular, Engage Communication offers IP Tube Protector for VoIP. Unfortunately this solution 1) is more of equipment than of standard technology and 2) is confined to VoIP domain only. It may be also worth noting Juniper Packet Redundancy technology, though it looks like limited to single link only, and not to redundant links.

I wonder why I can't find anything similar from Cisco… Does any standard or at least general purpose technology address this?

Best Answer

With Mikrotik routers, you can using bonding in broadcast mode, see bonding. I made some tests accross a 4G link connection, it does reduce packet loss going from 1 to 2 and I benefit from TCP speed improvements. Packet losses are not completely eliminated but going to 3 links does not further improve. I would investigate next in network coded TCP.