You missed the point of Mosh. SSH transfers a bidirectional stream of bytes between server and client. It uses TCP as transport. You can combine SSH with tmux to preserve your sessions as tmux sessions. If you use SSH to access your tmux session you fixed a part of the problem. Your client can now roam by reattaching the tmux session from a new SSH connection.
The other half of the problem remains: SSH transfers unmodified byte streams between client and server over TCP. On networks with high latency or high packet loss this design doesn't work. Mosh fixes this part of the problem by redefining the problem. Instead of transferring every byte in both directions it runs a terminal emulator on both sides and the problem turn into: keep the terminal emulator states in sync. The server sends patches from the last confirmed client state to the current server state to the last known client address:port pair via UDP. The client sends the user input (and pings) to the server via UDP. This design allows Mosh to skip over lost messages.
The other half of the problem remains: SSH transfers unmodified byte streams between client and server over TCP. On networks with high latency or high packet loss this design doesn't work. Mosh fixes this part of the problem by redefining the problem. Instead of transferring every byte in both directions it runs a terminal emulator on both sides and the problem turn into: keep the terminal emulator states in sync. The server sends patches from the last confirmed client state to the current server state to the last known client address:port pair via UDP. The client sends the user input (and pings) to the server via UDP. This design allows Mosh to skip over lost messages.