On Aug 11, 2017, at 12:07 PM, Juliusz Chroboczek <j...@irif.fr> wrote:
>> This is a refrain I've heard from you, Juliusz and Markus, which I actually
>> find a bit disturbing: the desire not to really solve the problem because 
>> it's
>> not trivially easy.
> 
> If I were in a bad mood, I'd say that the three of us prefer simple, robust
> solutions that solve actual problems to complex, brittle hacks that are
> not going to be implemented anyway.

Forgive me, Juliusz, but I don't lecture you on routing protocols, do I?   You 
are objecting to something that you don't see the need for, but the reason you 
don't see the need for it is not that there isn't a need for it.   It's that 
you haven't clearly understood the problem.   Now, you could certainly point 
the finger of blame at me for failing to explain it adequately, but I would 
appreciate it if you could do me the courtesy of not assuming that I am just 
trying to come up with a "complex, brittle hack that's not going to be 
implemented anyway" for my own amusement.

>> Think about the routing problem. We need source-specific routes. We're
>> extending babel to add them. Why is that? Couldn't we have just relied
>> on happy eyeballs to eliminate the bad routes?
> 
> No, we couldn't.  Happy eyeballs (or MP-TCP, or MP-QUIC, or MP-Mosh) uses
> the services provided by source-specific routing.  They work in combination.
> 
> (Come on, Ted.  You already knew that.)

Yes, I did, and that was precisely my point.   We need source-specific routing 
because happy eyeballs doesn't solve the problem: we want to support 
multi-homing, and that requires a more complex solution than would be needed if 
we could mandate that homenets have only a single connection to the internet.   
Mandating that homenets only have one Internet link would make the solution 
substantially less complex.

Source-specific routing, however, is an incomplete solution.   Having chosen 
the correct route based on the source address, we still have the problem that 
one provider connection may be better than another for connecting to a 
particular destination, and there may be no way to figure that out using the 
default source address selection algorithm, or even by using a more detailed 
source address selection algorithm configured by DHCP.   Indeed, this is 
likely, not unlikely.

> This has nothing to do with the amount of flash or RAM.  It has everything
> to do with having protocols that can be implemented in finite time and
> with a only a finite number of bugs, and with building networks that can
> survive whatever bugs remain.

I agree that we should not propose solutions that can only be implemented in an 
infinite amount of time.   But we already have implementations of MPvD support 
from several vendors.   So it's not even the case that the amount of time 
required to do this is long.   It's already mostly done for several important 
hosts, and one of those hosts is a Linux host, so the solution that works there 
will also work on regular Linux.

Implementing this on the router is straightforward.   I believe that it could 
actually be done with no changes to dnsmasq, although a better solution would 
make some changes, because doing so would make configuring it easier.

What I find completely perplexing about this conversation is that you, Markus 
and Toke, all of whom I know to be smart people, think this is hard.   What is 
hard about it?   I think the reason you think it's hard is simply that you 
don't know how to do it.   The unknown always seems hard.   That's something 
that we can fix by describing in the document how to do it.   If, after that, 
you still think it's hard, (a) I will be very surprised, and (b) we can think 
about whether it's worth the trouble.

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to