El 13 ag 2017, a les 9:32, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
> Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice
> to have" list, rather than the "absolutely required" list.
Why do you think CDNs exist? What would happen if every home network suddenly
stopped using the technology that makes CDNs work? You mentioned that you
don't use it, and your Netflix works fine, and that's my experience too (I have
the same configuration). But if everybody did that, I think it would not work
fine, and that's why we should make sure that out of the box, by default, it
works correctly. We want users of homenet to have a good experience, and to
be able to tune their experience if they want non-default behavior.
> Perhaps it would help if you could explain (a) the details of "the CDN
> problem" (what mechanism is used to determine answers for a given
> prefix, and what is the failure mode if the wrong address is used?), and
> (b) how the client is supposed to actually work with this mechanism
> (seems to me an unmodified client will probably make a mess of things?).
The idea with CDNs is that you put the content close to the edge and give
different answers using DNS or HTTP depending on where the client is. By
doing this, you can balance the load across the right number of servers in the
right data centers, and avoid transporting the same traffic over the backbone
many times.
> As for an "ideal" resolver behaviour, to me that would be full recursive
> resolution from the root inside the home, replicating all queries across
> all upstreams and picking the best reply (best being something like
> "first reply that passes DNSSEC validation"). With an "advanced
> configuration" option somewhere that allows the user to override
> arbitrary names/zones as they see fit.
This is mostly what the MPvD solution does (minus the override option, which I
think is out of scope). Queries are sent to all upstreams, and the good
answer that arrives first is used. What MPvD does _in addition_ is to make
sure that if ISP A's answer is chosen, then ISP A's connection is used to
connect to the destination.
MPvD also accounts for the fact that this connection might not work. It isn't
good enough to just select whichever DNS answer comes back first, because that
answer may not actually result in establishment of a successful connection.
So ideally you try both connections, either simultaneously or else according to
some algorithm that optimises for which connection is preferred.
For example, if you really, really want to use connection A, then you only try
connection B if you don't have a successful connection established after 30
seconds, but if you don't care, then you try both nearly simultaneously and
take the first one to succeed to the point where you have completed the https
handshake (for example) and validated the cert using PKI validation.
You may also want to configure things so that you have a primary and a backup
connection, and your backup connection is never used for certain things, or
only used for certain things. E.g., if your backup is a cell phone backup
that costs more per megabyte, or has a lower data cap. Or in some cases just
the opposite. This is useful for situations where you want to be able to have
dual-homing for the sake of IoT six-sigma reliability, but don't want to use
the backup link for anything else, because it's expensive.
Now, as for the "mostly" above, the problem with what you've said is that it
doesn't scale: if every home does full recursion, that's a much larger load on
authoritative name servers than currently exists. There's a reason why that's
not how things are done now. If we were to specify this behaviour, there
would be substantial pushback from dnsop, and I would be participating in that
pushback. I don't think this would get IETF consensus. This is not to say
that you are wrong, but the point is that this is the wrong working group in
which to have that argument.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
