El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <t...@toke.dk> va escriure:
> In any case, the failure mode of getting a it wrong is a sub-optimal
> path being chosen; but if ISP A's DNS server takes five seconds to
> respond, we'd get a better result from just using the timely answer from
> ISP B's and going over the suboptimal path to get to the content (in
> many cases, at least).
Not if the suboptimal path has substantially worse performance for the duration
of the session.
> But only the client can make that coupling (from DNS reply to connection
> attempt). So if we're just filtering the result set based on the address
> the client uses (which is how I interpret what you put in the draft),
> we're degrading the experience for any client that doesn't know how to
> repeat the query from another source address. So we'd effectively be
> requiring hosts to support MPvD; and we're not supposed to require host
> changes, are we?
Many hosts we care about already support MPvD because the companies that sell
the software that runs on those hosts think it solves a useful problem.
Adding support for MPvD on the homenet is a relatively small change now that
their stacks already support it.
As for a "degraded experience," do you mean that if we select one upstream
provider for a particular client, that's going to result in a degraded
experience for the user? Why would that be the case?
> I can see how these scenarios make sense for a device that know the
> types of connection (like a cell phone with cellular and WiFi links).
> Less so in the home, where all the client sees are different prefixes;
> in this case, either the network has to enforce policy (like the
> failover scenario), or we'll have to communicate more information to the
> hosts, which goes back to my point above about host changes...
Yes, in order to make this work we have to communicate additional information
to the host, and the host has to use it. That's why I described a fallback
solution for hosts that don't support this. It's not clear that the solution
I described is the right one, of course; the point of saying something there
was to have a place where we can write whatever the advice is that we decide to
give when we figure this out; what I described would work, but it's possible
that an entirely RA-based solution would work just as well, in which case
personally I'd prefer it.
> Right, well, I'm not sure I have the energy to go argue with dnsop on
> this one... :) But I can probably live with a mechanism where we just
> specify that the user needs to have an option to override the default
> behaviour (i.e., add their own DNS servers which take precedence over
> whatever we end up specifying).
That's fine with me!
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
