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

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen  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.

>> 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.

> 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.

>> 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?

>> 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!

Cool :)

-Toke

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

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

[Ted Lemon]

El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen  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

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

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

>> 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.

Yeah, I am aware of the basic concept of a CDN. What I am (was?)
confused about is what it has to do with different DNS answers. I have
only ever used Cloudflare, and they use anycast to do their magic (which
also seems to me like the obvious way to do it; why are people messing
with DNS for this?). Anyhow, consider me educated... :)

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).

>> 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.

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?

> 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.

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...

> 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.

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).

-Toke

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

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

[Ted Lemon]

El 13 ag 2017, a les 9:32, Toke Høiland-Jørgensen  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

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

[Toke Høiland-Jørgensen]

> The point is that what I have specified in the architecture document is
> what is minimally required to allow a homenet to function given ordinary
> ISPs and ordinary users.   I think trying to do some of the things on the
> above laundry list would be very interesting work; trying to get it to
> where end-users can use it without being experts and without being made
> vulnerable to scams would be very cool, but is out of scope for this
> document.
>
> Does that make sense?

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.

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?).

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.

-Toke

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

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

[Ted Lemon]

Hm.   What I think the ideal resolver to have on a homenet is as follows:

(1) It can be configured to scatter queries randomly to a large number of
resolvers all over the internet.
(2) It can be configured to send certain queries to forwarders provided by
one or more local ISPs
(3) It can be configured to filter domain names based on a subscribed list
(or a set of subscribed lists) of known-bad domains.
(4) It can be configured to provide its own answers for some set of names,
in order to break devices you own and have paid for out of
provider-supplied walled gardens.
(5) ...

However, this feels to me like it's a laundry list of features that are not
_required_ by a homenet.   Many of these features require a fair amount of
understanding to configure.   Doing (3) in the local resolver is actually
hard, because the list can be quite large, or else it's privacy-violating,
because you have to send your query stream to the thing that manages the
list.   Ideally (3) would be done on the same mass of resolvers that you
are using for (1), so as to keep the query stream private.

The point is that what I have specified in the architecture document is
what is minimally required to allow a homenet to function given ordinary
ISPs and ordinary users.   I think trying to do some of the things on the
above laundry list would be very interesting work; trying to get it to
where end-users can use it without being experts and without being made
vulnerable to scams would be very cool, but is out of scope for this
document.

Does that make sense?

On Sun, Aug 13, 2017 at 6:52 AM, Toke Høiland-Jørgensen 
wrote:

> Ted Lemon  writes:
>
> > 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.
>
> Ah no, this was not was I was trying to express. As you say, technically
> implementing what's currently in your draft is doable, but adds a small
> to moderate amount of complexity. This can be acceptable, *if* it
> provides a corresponding benefit. However, I do not believe that it
> does, for two main reasons:
>
> 1. In every encounter I've had with an ISP-provided DNS server, that
>server is either (a) flaky, (b) censored or (c) both. So limiting
>ourselves to getting replies from just one upstream for a given query
>is going to give worse performance than using all available servers
>(or just doing our own full recursing from the root).
>
> 2. Even if DNS queries are paired with source prefixes, the client still
>has to pick which source prefix to send the DNS query from; how is it
>going to do that? (This may just be me that is ignorant of the
>details of the MPvD architecture; if so, please do enlighten me).
>
> Together, these points mean that as far as I'm concerned, what you're
> proposing is adding complexity to achieve a behaviour that is going to
> result in *worse* performance than doing the simple thing. Which is not
> a good proposition, as I'm sure you'll agree.
>
> Now, as I said a few mails back, I am perfectly happy to be convinced
> that there *is* a benefit worth paying the complexity cost for; but,
> well, someone is going to have to do the convincing... :)
>
> -Toke
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Toke Høiland-Jørgensen]

Ted Lemon  writes:

> 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.

Ah no, this was not was I was trying to express. As you say, technically
implementing what's currently in your draft is doable, but adds a small
to moderate amount of complexity. This can be acceptable, *if* it
provides a corresponding benefit. However, I do not believe that it
does, for two main reasons:

1. In every encounter I've had with an ISP-provided DNS server, that
   server is either (a) flaky, (b) censored or (c) both. So limiting
   ourselves to getting replies from just one upstream for a given query
   is going to give worse performance than using all available servers
   (or just doing our own full recursing from the root).

2. Even if DNS queries are paired with source prefixes, the client still
   has to pick which source prefix to send the DNS query from; how is it
   going to do that? (This may just be me that is ignorant of the
   details of the MPvD architecture; if so, please do enlighten me).

Together, these points mean that as far as I'm concerned, what you're
proposing is adding complexity to achieve a behaviour that is going to
result in *worse* performance than doing the simple thing. Which is not
a good proposition, as I'm sure you'll agree.

Now, as I said a few mails back, I am perfectly happy to be convinced
that there *is* a benefit worth paying the complexity cost for; but,
well, someone is going to have to do the convincing... :)

-Toke

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