[mosh-devel] Impressed

Thu Apr 12 13:40:12 EDT 2012

Hi Dave,

The idea of setting the appropriate ToS/DiffServ code point in mosh-generated data makes sense.  Some questions:

1) What specific DiffServ Code Point would you recommend?  Does openwrt support EF?

2) Would the setting of the codepoint be treated consistently across different network elements? E.g., if we set a particular value but some other network treated it very differently, would it make things worse (I suppose it'll be fine as long as no one treats it as worse than best-effort).

3) What are CS4 and CS5?

And something in your email confuses me: isn't the primary issue in networks with deep buffers caused actually by the bulk transfers that occupy the queues?  So while mosh could in principle be careful not to fill up buffers, realistically, it might not have a huge impact in avoiding filling up queues because most of that fill up comes from non-mosh traffic anyway? Am I missing something?  Is the issue that ssh by itself fills up buffers badly during interactive sessions even when other traffic is minimal?

Keith and I have been working on other solutions/approaches to bufferbloat (which itself is a symptom of larger problems), but that's independent of the mosh software for the most part.

Hari

On Apr 12, 2012, at 1:23 PM, Dave Taht wrote:

> 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
> 
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel