[mosh-devel] Impressed

[Dave Taht]

On Wed, Apr 11, 2012 at 4:33 PM, Keith Winstein <keithw at mit.edu> wrote:
> Thanks Dave! I'm a big lurker on the bufferbloat list and appreciate your
> kind words.

You've taken a huge subset of the problem with bufferbloat (interactive ssh
management sessions suck) and taken care of it innovative, easy to deploy way,
that I'd never thought of.

Sysadmins around the world will rejoice. In my case I frequently
(purposely) blow up the lab network and losing my state on a dozen or
more ssh sessions is really annoying.

For the last two days, that hasn't happened. It's very relaxing.

"Mosh: better than valium. "

You can quote me on that. :)

My major kvetch, oh lurker, is that had I known about your project
before I'd absolutely
have take the time to toss it into cerowrt/openwrt! As it is, there seem to be
a few large dependencies that would need to be ported, and packaged,
and I'm too low on time before this release to do so myself.

A couple other notes: The current linux wifi stack does do categorization
into the 802.11e hardware queues, based on diffserv priority markings.

While these generally do not survive  transit across the internet,
they do seem to help locally on a congested network.

openssh tries to use the old tos-style imm bit, but due to the installed base
not respecting that, I suspect you'd get better results on congested
wifi if you tossed mosh's packets into CS4 or CS5 categories, which
will utilize the underused VI queue.

 (cerowrt tosses IMM into the VI queue, I really should push that
patch up to mainline)

Somewhat similarly, most of the bloat related solutions are working
best with ECN, and
it would be interesting to try turning that on, as packets marked with
that bit have a better
chance of survival through an AQM, and possibly getting some more
signaling from the path would help, on occasion.

I'm painfully aware that ECN appears hard to deploy,
but it seems to me you could attempt a robust solution in your protocol here.

> We plan to support IPv6, and there are some user branches on github that get
> us working IPv6 for IPv6-only hosts. The problem is that for dual-stack
> hosts, we think it's pretty likely that the user may start up over IPv6 but
> later want to roam to a cellular network (e.g. LTE) that supports IPv4 only.
> We want this to keep working as well as it does today.
>
> I haven't found other applications that have successfully implemented
> cross-protocol roaming -- I think it raises some new issues. (At the IETF
> last month we had some discussion about the various ways this could be done
> but nobody seemed confident in a pre-existing approach that would work.)
>
> Right now we look up the server's A records, the resolver picks one, and we
> use that as the IPv4 address (for both the initial SSH connection that
> remotely executes the mosh-server, and then for the mosh-client to connect
> to the mosh-server).
>
> If we support IPv6 and v4, then we're going to potentially get back four
> AAAA records and seven A records. How do we know which pairs correspond to
> the same host? Right now the client's roaming is totally stateless and it
> has no idea that it has even roamed (it just keeps sending heartbeats to the
> same target IPv4 address).
>
> So to do this properly, we'll probably have to provide the client with a
> list of possible IPv6 and IPv4 addresses (every AAAA and A record we got
> back), and have it start out sending packets to all of them over each
> protocol. Whichever one it gets a (cryptographically authentic) reply from
> it can lock onto, but if it ever goes more than a few seconds without a
> reply from the server, it will have to fall back to the mass-send approach
> again.
>
> This is like Happy Eyeballs on steroids.
> (http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07)

It's good to know there are branches that do ipv6, and I agree that
super-happy-eyeballs would be required, and a PITA.

> The datagrams all represent idempotent operations so I don't think there's
> any theoretical obstacle here, but it means adding logic and state to the
> client for something that right now is very dumb.
>
> So... we're working on it! :-)
>
> Best regards,
> Keith
>
>
> On Wed, 11 Apr 2012, Dave Taht wrote:
>
>> I've been fiddling with mosh in the lab here and I'm really impressed.
>>
>> I need to read up on your underlying protocol a bit, but right now
>> I'm no longer as motivated to finish fixing tcp.
>>
>> In what state is the ipv6 support?
>>
>> --
>> Dave Täht
>> http://www.bufferbloat.net
>>
>> _______________________________________________
>> mosh-devel mailing list
>> mosh-devel at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/mosh-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net