Entering the mosh pit

Posted May 17, 2017 9:37 UTC (Wed) by obonaventure (guest, #108715)
Parent article: Entering the mosh pit

Instead of changing the application to support mobility, another solution is to change the underlying transport protocol. When ssh is used over Multipath TCP, all the mobility features provided by mosh come for free thanks to the underlying Multipath TCP. All the features of ssh, including port forwarding, continue to work. If TCP reset attacks are a concern, Multipath TCP can cope with such attacks by recreating subflows and it would be possible to use ssh implementations to better interact with Multipath TCP. Patches are available for various versions of the Linux kernel from http://www.multipath-tcp.org

Entering the mosh pit

Posted May 17, 2017 12:30 UTC (Wed) by pabs (subscriber, #43278) [Link]

Have the patches been submitted for mainline Linux?

Entering the mosh pit

Posted May 17, 2017 12:42 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Downside: the middleboxes presumably have to support MPTCP or at least not block it. The time before a random satellite Internet provider supports *that* is probably measured in the centuries :(

MPTCP

Posted May 17, 2017 13:03 UTC (Wed) by corbet (editor, #1) [Link]

MPTCP is rather carefully designed to sneak through middleboxes; that's where a lot of the complexity in the protocol comes from. Some details are in my 2013 article on the subject.

Unfortunately, the work to upstream this code seems to have stalled completely.

Entering the mosh pit

Posted May 20, 2017 7:54 UTC (Sat) by obonaventure (guest, #108715) [Link] (1 responses)

Apple has been using MPTCP for Siri on all iPhones, iPads and now MacOS devices without observing severe problems caused by middleboxes deployed on the Internet. MPTCP works well through those middleboxes.

Entering the mosh pit

Posted May 20, 2017 11:41 UTC (Sat) by nix (subscriber, #2304) [Link]

Oh, excellent! Now all we have to do is get it merged :)

Entering the mosh pit

Posted May 17, 2017 17:24 UTC (Wed) by shemminger (subscriber, #5739) [Link] (4 responses)

Using UDP and reinventing own flow control and retransmit is foolish.
"Those who do not understand TCP are doomed to reinvent it"

Entering the mosh pit

Posted May 17, 2017 21:24 UTC (Wed) by itvirta (guest, #49997) [Link]

> Using UDP and reinventing own flow control and retransmit is foolish.

Perhaps, but it does have the advantage that it works without any kernel support.
Which helps a lot in getting your software to work across different operating systems.

In mosh's case, it also has the upside that it knows more about the underlying data
than a general purpose stream transmission algorithm does. Namely, changes to the
screen can be mercilessly discarded when the client isn't looking.

Entering the mosh pit

Posted May 17, 2017 22:42 UTC (Wed) by renox (guest, #23785) [Link]

Your comment lacks substance, I could also say those who understand TCP try to replace it!
For example I hate having to type sleep 30 to prevent me from trying "too soon" to restart an application which then fail because the TCP connection fail.

Entering the mosh pit

Posted May 17, 2017 23:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Using UDP and reinventing own flow control and retransmit is foolish.
Nope. Mosh is essentially a media application - it transmits the live video of the remote terminal.

So it's much better to transmit the whole screen state anew if an update packet is lost rather than wait for TCP retries to deliver all the intermediary packets.

For the same reason voice/video conferences use UDP - it's better to simply drop a small update to compensate for it later rather than cause the whole screen to stutter while the stream recovers.

>"Those who do not understand TCP are doomed to reinvent it"
Those who think that TCP is The Answer are foolish in the extreme.

Entering the mosh pit

Posted May 20, 2017 7:28 UTC (Sat) by niner (subscriber, #26151) [Link]

No idea if mosh does it, but since it transfers very little data and may be used over networks with large packet loss, it could even opportunistically retransmit. Just send each package twice or even more to increase the chance that at least one of them arrives.