TCP cannot "tolerate" 50% packet loss. It will simply grind to a halt, for a simple reason: it adapts its transmission speed based on the loss of packets. When packets are lost, they are understood to indicate congestion. If you drop 50% of packets (say, with a random drop firewall rule) regardless of traffic, it will see an ever decreasing bandwidth availability.
Furthermore I doubt ISPs shape ICMP vs TCP. Some might do, as there are some really stupid people out there, but it doesn't make much sense to do so. Most will shape the whole connection, or it will "shape itself" because of congestion. In either cases packets are typically dropped randomly.
That being said, you can ping with TCP, but there are several caveats. The first is to just send the initial packet in a TCP connection, which will elicit a response from a server with an open port, but will be seen as a connection attempt. Ideally you could use the "echo" service (TCP port 7) ... but actually you can't because it's now disabled by default everywhere. Anyway, if you can get someone to enable it for you on the machine you want to test, a program could use that to check the round-about time for packets inside a TCP connection.
That being said, you probably have the "tracepath" command installed on your machine; it's similar to traceroute but uses neither TCP or ICMP, but UDP. For TCP there are various utilities out there, you can try hping.