Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

[Ted Lemon <[e-mail]>]

El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen <[e-mail]> va escriure:
>> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <[e-mail] <mailto:[e-mail]>> 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.
> 
> Sure, it depends on the particular application (hence the "in many
> cases" in my original statement)... My point is just that it's not an
> obvious across the board win.

Indeed.  However, it is never a lose.

>>> 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.
> 
> Right, so we're adding it as an extra service for hosts that support it?
> That is fine with me, but then it shouldn't be a requirement. I.e., we
> can go "supporting MPvD is a good idea, and here is how you do it
> correctly", rather than the current "must support" language.

If we don't require it, we can assume that it will not be supported.   It is likely that most hosts will support it, so if we don't support it, we are missing an opportunity to make things work well on the homenet, not just failing to add a "nice to have" feature.

>> 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 mean that if we query all upstreams we get the best aggregate
> performance from all available DNS servers. Whereas if we limit queries
> to a particular ISP, we only get as good performance as that particular
> ISP can provide. If that was going to be the best on anyway, fine. If
> not, we are worse off by limiting queries to that ISP.

If one ISP is performing substantially worse than the other, the right thing to do is use only the one that's performing well.   Neither "doing nothing" nor "doing MPvDs" accomplishes this end.   However, "doing MPvDs" arguably comes closer.   The downside is that if the lousy ISP wins, hosts are stuck with it.   This is a serious problem.   It may indeed be the case that a better choice for non-MPvD hosts is to give them a name server that fans out to both ISPs.

>>> 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.
> 
> How do non-MPvD-aware hosts react to an announcement of an MPvD-specific
> DNS server? Does it ignore the server entirely, or does it ignore the
> PvD information and use the server anyway?

It has to be announced in such a way that non-MPvD hosts don't see it.