Maybe in a perfect world, but given that all ISPs are not created equal, it is usually the case that the two paths don't have the same latency and packet loss characteristics.

That's the point I'm trying to make. In the real world these don't actually matter, in terms of meaning that asymmetric routing itself presents a TCP performance problem. The two directions of a symmetric path can also have different packet loss characteristics, due to different levels of congestion. So this is not a problem specific to asymmetric routing. (It's also usually not a problem for bulk-transfer TCP because the acks take so little bandwidth compared to the data, and loss of an ack is not as serious as loss of a data packet because acks are cumulative.) That the two directions of an asymmetric path have different latencies doesn't in most ways matter either. TCP's performance is determined by the RTT - whether it can fill the pipe, whether it times out and retransmits correctly - and not by the unidirectional prop time. The only major real-world application I came across that has trouble with asymmetric routing is NTP. It has robust algorithms to avoid being fooled by asymmetric paths, but if two NTP communities are only connected by an asymmetric path, then they will indeed keep incorrect time with respect to one another (assuming they're not separately synchronized, which of course is how you solve this problem in practice). Asymmetric routing is also a network measurement and troubleshooting pain - I don't mean to discount that. Vern