Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Dave Taht <[e-mail]>]

On Thu, Dec 18, 2014 at 7:38 PM, Brian E Carpenter
<[e-mail]> 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