OK, from the top;
Down vote on your question from me; your question isn't clear enough based on your responses in comments to other peoples answer. You have assumed the solution is networking engineering related but you don't seem to know, and give the impression that you hope someone is going to give you the answer you need.
You have the following problem requirement;
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
- Unless your end host's connection to their local router is double the speed of the traffic going over a single link between
router2, which you haven't mentioned, your hosts will need two connections to their local router. There is NO native software or product ANYWHERE that can run on an end hosts and take two TCP streams down the same NIC or two separate ones and pull from an alternate stream missing packets from the first stream. How do I know this? Because that is not how networking works, IP & TCP simply weren't designed to work like that. There maybe products for duplicating packets, but these are a niche, not wide spread, becasue it's the wrong answer to the question.
Why is this such a bonkers request;
You seem to be trying to put a round peg into a square hole. My understanding of your problem requirement is that you want redundancy for your application's data travelling between to remote hosts. Data is sent twice end to end in case of a link failure. That is all you are protecting against here with dual TCP flows though, physical layer 1 failure. If there is a pause in sending a packet from one host to the other, it will be late arriving down both router-to-router links. If a transient problem occurs on one link but not the other, such as congestion, the router at the end of the link, would need to track both TCP streams simultaneously to see that when a packet arrives on link2 with the proceeding sequence number in its header, and nothing has arrived on link1, then the packet on link1 is late, and if it does turn up, it needs to drop it.
What if you find your self in a situation where there is congestion on link1 but no traffic is dropped, due to a good QoS schema, but it is queues, packets down link1 are now always behind link2. What if link2 fails now and the router passes packets on link1 to the end hosts, it's going to receive dup packets, and stop and retransmit etc, and cause a delay. Nothing was achieved here.
Moving on to a solution;
A better idea in my opinion would be to have dual layer 2 links between the two end hosts, extending their broadcast domains to include each others NIC. You can do this via direct layer 2 interconnects, MPLS/VPLS extension, carrier layer 2 service, take you pick, that isn't strictly relevant here. Extending the layer 2 network between hosts means you don't need to mess with TCP or do any crazy black magic or band-aid type fixes. TCP will be completely agnostic of the underlying technology and you will still have you layer 1 / physical link redundancy.
If you use an MPLS based solution you can use features like traffic engineering (MPLS-TE) to monitor the latency across the links and always use the link with the lowest latency. You can use BFD with MPLS FRR, which can get you 50ms~ fail over time between links. I know you said you don't want a redundancy fail over solution, but 50ms is pretty fast in my opinion. If your application can't handle a 50ms loss of connectivity, then you need to go back to the application drawing board. No system is up 100% of the time, you must plan for failures, planned maintenance, and outages through malicious intent / security related; to all occur at some point. You must be realistic.
In one comment you said the following;
well, IP SLA is the technology being used at least at one end so
far... :) still it takes quite a time for both ends to detect link
failure, and the application gets out of sync sometimes... and the
links may be twinkling sometimes... that's why we are looking for
No such thing; Time must pass for possible events to become actualities. You need to re-think this to an "acceptable" level of delay.
Also in another comment you said;
BGP it takes quite a time to discover that the route deemed
operational is now down; finally the routers realize this and switch
active routes, but it takes time, and application-level protocol may
BGP has a hello timer, this is detecting the the presence of it's immediate neighbour. Default is 30 seconds, I suspect this is what you are referring too. If both routers in your topology speak BGP with the ISP at each site or even directly to each other, over those peerings build IP-in-IP tunnels of GRE or L2TP(v3) tunnels between the two routers, over those tunnels run BFD or IP SLA. Now you can detect end-to-end connectivity loss in 1 or 2 seconds, and reroute to the other tunnel using tacking objects.
All in all, you seem to be mixing up different layers of technology. BGP isn't suppose to provide fast re-routing, TCP isn't supposed to be duplicated, and so on. You're looking at the wrong levels of abstraction to tackle this problem. I hope this has helped.