On Thu, Dec 18, 2014 at 7:38 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > On 19/12/2014 14:49, Juliusz Chroboczek wrote: >>>> Boutier's version of mosh builds connections across all source/destination >>>> pairs, and picks the one with lowest RTT. >> >>> Sounds interesting. In the ideal world, that would be a pluggable >>> policy algorithm. Lowest RTT may not always be the best choice. >> >> It is, in our particular context. That's the nice thing about working at >> the application layer -- you are the application, so you have a pretty >> good idea of what the desirable properties are. Mosh is an interactive >> shell, and in this particular context it's latency you want to optimise >> for. > > Are you sure?
For mosh, which is a very low bandwidth, highly interactive application, lowest RTT is the right choice. > Suppose I open a file transfer window (which as a matter > of fact I do almost every time I use SSH these days). For large file > transfers > I might want to specify "cheapest" not "fastest". I would argue that a transfer over LTE (which is the most expensive option), would generally exhibit higher RTT over any other method. lowest financial cost does not have a whole lot of meaning otherwise along the edge. Highest bandwidth or least congested might be other selectors... But: in kicking off this thread, what I was mostly thinking about was making a choice between 9 or more ipv6 addresses to choose from, what to start with, and when to give up. (and which ones should end up in DNS) It seemed to me that I should longest prefix match, except when other characteristics of the route interfered. As one example it made sense to choose a native connection over a tunneled one. As another example, when there was a vpn in play (with it's own address range) to try to use the vpn rather than any public addresses that existed. And then there is a choice to try and prefer stabler addresses (infinite lifetime) over addresses with shorter lifetimes. And then, in order to have a better choice of multi-path connectivity, for an app like mosh or something using mptcp, to chose addresses that are wildly different. I would argue for an app that wants multiple forms of connectivity to pick 3-5 addresses total (and for mosh, to ensure it did ipv4 and ipv6). I tossed hip in there just to make things difficult, as arguably hip addresses should only be used when trying to contact another device in the hip address range ( 2001:10::/28 ) >> Once we gain some real-world experience from mosh, we can think about >> making something more generic. But I, at least, don't feel comfortable >> about doing that. > > Understood. But all I'm thinking is that you might make that bit a > self-contained > module. Well, I think I was seeking a new API here. But writing a select or poll loop for 9 addresses is not much harder than 2. > > Brian -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
