Maybe an option to choose an alternative controller via socket options (linux and windows offer alternatives) would make sense in some situations.
Default TCP congestion control is Reno, but Linux uses Cubic, increased initial CWND and all the other modern modifications. CDNs have their own proprietary congestion controls that are arguably better, but Google has already pushed its own congestion control (BBR) into Linux, so it is just a matter of time until it becomes new default. There is no reason to tamper with these settings unless you are operating Netflix/YouTube, some sort of CDN or unusual (satellite) link.
> Maybe an option to choose an alternative controller via socket options (linux and windows offer alternatives) would make sense in some situations.
Only the server congestion control matters. Client simply acknowledges whatever it receives as soon as possible and waits for more data.
To be clear, that's true if the server is the only one transmitting data. (I.e. for a download)
What kind of logic should this app use to determine how many external addresses are actually available in the case of IPv4? As you say, it is more "tcp fair" to have only one TCP connection per client/server relationship in normal cases.
Just some random thoughts. Apologies if it's difficult to follow. I can reply to any questions if anything is confusing.
Opening one connection per interface is still a violation of TCP design. Look into MPTCP RFCs. It is specifically designed to use multiple connections as if you had only one. Developers of the standard made sure you don't have any advantage compared to someone using only one connection.
Two connections over two different interfaces will meet somewhere on the bottleneck near the mirror so you still have the advantage of multiple TCP connections.
Sure MPTCP is not ready yet, but multipath QUIC will be deployed by the end of this year so all your Chrome downloads from google drive will utilize multiple connections.