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

[Juliusz Chroboczek]

>> If the fast connection's DNS server replies after a delay or not at all,
>> and the slow connection's DNS server replies in a timely manner, using
>> a smart resolver across all the available DNS servers will improve latenc

> Yes, but if your fast connection is lossy, it's not fast. Lossy looks like
> congestion, so TCP slows down.

I never said the fast connection was lossy.  The scenario I'm envisioning
is one in which the DNS server behind the fast link is laggy.

Ted, DNS latency is a significant part of what the web people call "time
to first byte".  DNS resolvers make serious efforts to minimise that
latency by keeping RTT and loss statistics and picking the best resolver.
I don't know if you agree, but I suspect that any protocol that causes web
latency to increase is not going to get deployed easily.

-- Juliusz

___
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 18 ag 2017, a les 5:40, Juliusz Chroboczek  va escriure:
> If the fast connection's DNS server replies after a delay or not at all,
> and the slow connection's DNS server replies in a timely manner, using
> a smart resolver across all the available DNS servers will improve latenc

Yes, but if your fast connection is lossy, it's not fast.   Lossy looks like 
congestion, so TCP slows down.   There's nothing we can do in the resolver to 
fix this.   You want less complexity, but to successfully determine which link 
is the right one to use at the network level is a very hard problem, much 
harder than anything we are talking about here.   It might be an interesting 
research topic, but it doesn't make sense for you to raise it as an argument in 
favor of one or another options for configuring resolvers.

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

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

[Juliusz Chroboczek]

> I don't think anything we are talking about here would actually help
> with that.

If the fast connection's DNS server replies after a delay or not at all,
and the slow connection's DNS server replies in a timely manner, using
a smart resolver across all the available DNS servers will improve latency.

Both dnsmasq and (I believe) bind will do the smart thing.  (Which does
not consist in sending the request to all servers, contrary to what you
appear to believe.)

-- Juliusz

___
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 17 ag 2017, a les 16:10, Gert Doering  va escriure:
> 1990s never had uplinks that fast *and* unreliable at the same time 
> as many of today's consumer ISPs offer.

That was my point: you tunnel to the 1990's to get the leased line (a term that 
I think most people would just squint at nowadays and have no idea what you 
meant).   The lossy fast connection you'd get to directly—no need for a 
wormhole.   But in practice, (a) the lossy connection isn't anywhere near as 
lossy as you are implying; if it were, you couldn't use it.  And (b) even if it 
were, I don't think anything we are talking about here would actually help with 
that.   So I think it would be wise if we took this use case off the table, 
unless someone can characterize it better.   Reasoning on the basis of 
charicatures isn't going to get us anywhere.

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

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

[Gert Doering]

Hi,

On Wed, Aug 16, 2017 at 05:49:54PM -0400, Ted Lemon wrote:
> It's never for that purpose. It's to combine to normal connections so as to
> increase reliability. The scenario you just described would require a
> wormhole with one end in the 1990s.

1990s never had uplinks that fast *and* unreliable at the same time 
as many of today's consumer ISPs offer.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279

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

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

[Michael Richardson]

Juliusz Chroboczek  wrote:
> That's exactly the kind of situation that we'd like Homenet to work well
> in.  Connection A is a 1.5Mbit/s leased line, it's rock solid, and has
> rock solid infrastructure behind it.  Connection B is consumer FTTH at
> 1Gbit/s, it's flaky, and it's backed by infrastructure that works on
> Mondays only.

> Quite frankly, if it's not for combining fast with reliable, I just don't
> see what's the purpose of having multiple connections.

The 1.5Mb/s is for "work" use only (is very low-latency too), but tolerates
some moderate amount of non-work traffic, as long as it's not so much that
anyone notices.  That's why you'd have two connections.  Work traffic SHOULD
not go out the flaky connection.

That the result is what you describe (which I believe 200%...) is what
happens is not the plan.  It's not why the multiple connections are justified.
Now, assume a second spouse working at home, with another "work" connection :-)
(And of course, don't forget the mesh network to the neighbourhood)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
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]

It's never for that purpose. It's to combine to normal connections so as to
increase reliability. The scenario you just described would require a
wormhole with one end in the 1990s.

On Aug 16, 2017 5:25 PM, "Juliusz Chroboczek"  wrote:

> > I think this is a real edge case. You have two connections, the DNS
> server on
> > one of them is broken, the DNS server on the other is not, but the second
> > connection performs so much worse than the first
>
> That's exactly the kind of situation that we'd like Homenet to work well
> in.  Connection A is a 1.5Mbit/s leased line, it's rock solid, and has
> rock solid infrastructure behind it.  Connection B is consumer FTTH at
> 1Gbit/s, it's flaky, and it's backed by infrastructure that works on
> Mondays only.
>
> Quite frankly, if it's not for combining fast with reliable, I just don't
> see what's the purpose of having multiple connections.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

> I think this is a real edge case. You have two connections, the DNS server on
> one of them is broken, the DNS server on the other is not, but the second
> connection performs so much worse than the first

That's exactly the kind of situation that we'd like Homenet to work well
in.  Connection A is a 1.5Mbit/s leased line, it's rock solid, and has
rock solid infrastructure behind it.  Connection B is consumer FTTH at
1Gbit/s, it's flaky, and it's backed by infrastructure that works on
Mondays only.

Quite frankly, if it's not for combining fast with reliable, I just don't
see what's the purpose of having multiple connections.

-- Juliusz

___
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:

> El 16 ag 2017, a les 9:40, Ted Lemon  va escriure:
>> Ah, if this is your concern, I think that's answered by the whitelisting 
>> stuff I was talking about earlier.   But in this case you really do need to 
>> have separate caches per PvD, and the MPvD-aware clients on the net need to 
>> be able to use them.   We could say that this is optional to support, 
>> though, and so if you want to pay for one router with this feature, that 
>> router's resolver can be advertised in the PvD-aware path.
>
> BTW, I think we have probably carried this discussion as far as is
> useful until a new rev of the draft is done. Daniel is working on a
> new draft, he said, and when he's done his bit I'll do a pass as well
> and try to capture the changes we've discussed here, and then we can
> iterate again. :)

Yup, fine with me :)

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

> El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen  va escriure:
>> Ted Lemon > writes:
>> 
>>> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen  va 
>>> escriure:
> In both of these cases, you are better off doing what we discussed
> earlier and setting up your own DNS cache, possibly with a whitelist
> for domains you want to send to the ISP forwarder.
 
 Sure, and that's what I usually do. But if we can't specify that
 behaviour for homenet, at least trying all upstream DNS servers gives a
 better chance of finding one that works.
>>> 
>>> I'm really sorry, but I'm actually having trouble contextualizing the
>>> failure mode that you are talking about here.   Didn't I agree with
>>> you in a previous message that we should try all the upstream DNS
>>> servers?
>> 
>> Hmm, right, I guess you did. My point was more that an MPvD-aware client
>> that only uses on PvD may experience worse performance than one that
>> uses the in-home resolver. But I guess the client should be smart
>> enough to deal with that?
>
> I think this is a real edge case. You have two connections, the DNS
> server on one of them is broken, the DNS server on the other is not,
> but the second connection performs so much worse than the first that
> you'd rather use an answer from the DNS server on the second to
> contact a service on the first.

Well, it's quite clear from this discussion that we have different ideas
about how likely this is. I think we'll just have to agree to disagree
on that, for now at least...

> If you were in an engineering staff meeting trying to justify adding
> extra code to do this, what would you have to say to get the group to
> agree to do the work? What would that code look like?

Ah, but I'm not arguing for adding code, I'm arguing that we should
remove some :)

-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 16 ag 2017, a les 9:40, Ted Lemon  va escriure:
> Ah, if this is your concern, I think that's answered by the whitelisting 
> stuff I was talking about earlier.   But in this case you really do need to 
> have separate caches per PvD, and the MPvD-aware clients on the net need to 
> be able to use them.   We could say that this is optional to support, though, 
> and so if you want to pay for one router with this feature, that router's 
> resolver can be advertised in the PvD-aware path.

BTW, I think we have probably carried this discussion as far as is useful until 
a new rev of the draft is done.   Daniel is working on a new draft, he said, 
and when he's done his bit I'll do a pass as well and try to capture the 
changes we've discussed here, and then we can iterate again. :)

___
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 16 ag 2017, a les 9:33, Toke Høiland-Jørgensen  va escriure:
> Ah, I wasn't trying to imply that ISPs deliberately design sub-par
> services just to annoy their customers; sorry if it came across that
> way. My "broken by design" comment was referring specifically to
> DNS-based censorship [1].

Ah, if this is your concern, I think that's answered by the whitelisting stuff 
I was talking about earlier.   But in this case you really do need to have 
separate caches per PvD, and the MPvD-aware clients on the net need to be able 
to use them.   We could say that this is optional to support, though, and so if 
you want to pay for one router with this feature, that router's resolver can be 
advertised in the PvD-aware path.

___
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 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen  va escriure:
> Ted Lemon > writes:
> 
>> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen  va 
>> escriure:
 In both of these cases, you are better off doing what we discussed
 earlier and setting up your own DNS cache, possibly with a whitelist
 for domains you want to send to the ISP forwarder.
>>> 
>>> Sure, and that's what I usually do. But if we can't specify that
>>> behaviour for homenet, at least trying all upstream DNS servers gives a
>>> better chance of finding one that works.
>> 
>> I'm really sorry, but I'm actually having trouble contextualizing the
>> failure mode that you are talking about here.   Didn't I agree with
>> you in a previous message that we should try all the upstream DNS
>> servers?
> 
> Hmm, right, I guess you did. My point was more that an MPvD-aware client
> that only uses on PvD may experience worse performance than one that
> uses the in-home resolver. But I guess the client should be smart
> enough to deal with that?

I think this is a real edge case.   You have two connections, the DNS server on 
one of them is broken, the DNS server on the other is not, but the second 
connection performs so much worse than the first that you'd rather use an 
answer from the DNS server on the second to contact a service on the first.

If you were in an engineering staff meeting trying to justify adding extra code 
to do this, what would you have to say to get the group to agree to do the 
work?   What would that code look like?

Sometimes things are just broken.   Expecting a homenet router to solve every 
possible configuration screwup on the part of the ISP isn't realistic.   As 
customers of these ISPs, we expect them to do a decent job, and if an ISP fails 
often enough to make this code worth writing, they probably need to be in a 
different business.

>>> You may be right that hacking up a working prototype isn't that hard.
>>> But the failure modes change from "the internet is down" or may "I
>>> cannot access site A", to "site A is working every third attempt, except
>>> it is entirely broken on device X" maybe even with an added "ah, but
>>> it works on device X if I go into the kitchen".
>> 
>> Didn't we agree that we aren't round-robining?
> 
> Yeah, but I was referring to the failure mode for MPvD vs non-MPvD
> clients. I.e. if one of the resolvers fails for whatever reason, only
> MPvD-aware clients that happen to select that PvD will notice; whereas
> if there's only one resolver it will be very obvious when it's not
> working...

That's not how PvDs work.   You don't select one and only use that.   You try 
both.

>>> Hmm, while writing this is occurred to me that it might make sense to
>>> just export the ISP DNS server(s) directly in the MPvD-only RAs?
>> 
>> This would certainly work, but now you can't have your nice local
>> resolver that does what you want.   However, I think you are right
>> that this is the right default behavior for MPvD-aware devices.
> 
> I would keep the in-home resolver for clients that do not support MPvD;
> and probably also announce it as a separate PvD for MPvD-aware clients?
> 
> Also, I think I would prefer running a single resolver in the home,
> rather than running one on every router.

I think there's some text in the document that was put in before I did the 
dnssd discovery relay stuff and hasn't been updated since.   There does need to 
be a dnssd discovery relay running on every router.   And if the dnssd 
registration protocol is running over unicast, then we need some kind of relay 
on port 53 on every router, so that we can tell that the device that's doing 
the registration is on the local link.   If we do the registration through the 
discovery relay, this isn't necessary.   I don't remember how Stuart specified 
this, so I'm not sure.

But the motivation for doing this is not that every router has to have a 
caching recursive resolver running on it.

___
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]

Ralf Weber  writes:

> Moin!
>
> On 15 Aug 2017, at 21:38, Toke Høiland-Jørgensen wrote:
>> Ted Lemon  writes:
>>> I think we are wandering off into nonsense territory here.   Have you
>>> observed this sort of problem in the field?   If so, can you describe
>>> what happened?   If not, why would we optimize for it?
>>
>> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
>> more fortunate with your ISPs than me. And that's before even going into
>> the DNS censorship issue; in my part of the world ISP DNS servers are
>> broken *by design*.
> And we wonder why there is no ISP/operator participation in the IETF...
> Your email address indicates you live in Denmark. I personally know people
> at ISPs in Denmark who run DNS resolvers for their customers and I in a
> previous job ran DNS servers for customers in Denmark, although the actual
> servers where located in Sweden and Germany. I can assure you that neither
> I nor my colleagues design DNS servers to be broken. If you have an issue
> with your ISP open a ticket with them and if they can't fix it switch ISPs.
> But don't blame all the ISPs to deliver broken service, without
> evidence.

Ah, I wasn't trying to imply that ISPs deliberately design sub-par
services just to annoy their customers; sorry if it came across that
way. My "broken by design" comment was referring specifically to
DNS-based censorship [1].

-Toke

[1] https://en.wikipedia.org/wiki/Censorship_in_denmark#Internet_censorship

___
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:

> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen  va escriure:
>>> In both of these cases, you are better off doing what we discussed
>>> earlier and setting up your own DNS cache, possibly with a whitelist
>>> for domains you want to send to the ISP forwarder.
>> 
>> Sure, and that's what I usually do. But if we can't specify that
>> behaviour for homenet, at least trying all upstream DNS servers gives a
>> better chance of finding one that works.
>
> I'm really sorry, but I'm actually having trouble contextualizing the
> failure mode that you are talking about here.   Didn't I agree with
> you in a previous message that we should try all the upstream DNS
> servers?

Hmm, right, I guess you did. My point was more that an MPvD-aware client
that only uses on PvD may experience worse performance than one that
uses the in-home resolver. But I guess the client should be smart
enough to deal with that?

>> You may be right that hacking up a working prototype isn't that hard.
>> But the failure modes change from "the internet is down" or may "I
>> cannot access site A", to "site A is working every third attempt, except
>> it is entirely broken on device X" maybe even with an added "ah, but
>> it works on device X if I go into the kitchen".
>
> Didn't we agree that we aren't round-robining?

Yeah, but I was referring to the failure mode for MPvD vs non-MPvD
clients. I.e. if one of the resolvers fails for whatever reason, only
MPvD-aware clients that happen to select that PvD will notice; whereas
if there's only one resolver it will be very obvious when it's not
working...

>> Hmm, while writing this is occurred to me that it might make sense to
>> just export the ISP DNS server(s) directly in the MPvD-only RAs?
>
> This would certainly work, but now you can't have your nice local
> resolver that does what you want.   However, I think you are right
> that this is the right default behavior for MPvD-aware devices.

I would keep the in-home resolver for clients that do not support MPvD;
and probably also announce it as a separate PvD for MPvD-aware clients?

Also, I think I would prefer running a single resolver in the home,
rather than running one on every router.

-Toke

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

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

[Ralf Weber]

Moin!

On 15 Aug 2017, at 21:38, Toke Høiland-Jørgensen wrote:
> Ted Lemon  writes:
>> I think we are wandering off into nonsense territory here.   Have you
>> observed this sort of problem in the field?   If so, can you describe
>> what happened?   If not, why would we optimize for it?
>
> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
> more fortunate with your ISPs than me. And that's before even going into
> the DNS censorship issue; in my part of the world ISP DNS servers are
> broken *by design*.
And we wonder why there is no ISP/operator participation in the IETF...
Your email address indicates you live in Denmark. I personally know people
at ISPs in Denmark who run DNS resolvers for their customers and I in a
previous job ran DNS servers for customers in Denmark, although the actual
servers where located in Sweden and Germany. I can assure you that neither
I nor my colleagues design DNS servers to be broken. If you have an issue
with your ISP open a ticket with them and if they can't fix it switch ISPs.
But don't blame all the ISPs to deliver broken service, without evidence.

So long
-Ralf

___
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 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen  va escriure:
>> In both of these cases, you are better off doing what we discussed
>> earlier and setting up your own DNS cache, possibly with a whitelist
>> for domains you want to send to the ISP forwarder.
> 
> Sure, and that's what I usually do. But if we can't specify that
> behaviour for homenet, at least trying all upstream DNS servers gives a
> better chance of finding one that works.

I'm really sorry, but I'm actually having trouble contextualizing the failure 
mode that you are talking about here.   Didn't I agree with you in a previous 
message that we should try all the upstream DNS servers?

> You may be right that hacking up a working prototype isn't that hard.
> But the failure modes change from "the internet is down" or may "I
> cannot access site A", to "site A is working every third attempt, except
> it is entirely broken on device X" maybe even with an added "ah, but
> it works on device X if I go into the kitchen".

Didn't we agree that we aren't round-robining?

> Hmm, while writing this is occurred to me that it might make sense to
> just export the ISP DNS server(s) directly in the MPvD-only RAs?

This would certainly work, but now you can't have your nice local resolver that 
does what you want.   However, I think you are right that this is the right 
default behavior for MPvD-aware devices.

___
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:

> El 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen  va escriure:
>>> I think we are wandering off into nonsense territory here.   Have you
>>> observed this sort of problem in the field?   If so, can you describe
>>> what happened?   If not, why would we optimize for it?
>> 
>> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
>> more fortunate with your ISPs than me. And that's before even going into
>> the DNS censorship issue; in my part of the world ISP DNS servers are
>> broken *by design*.
>
> In both of these cases, you are better off doing what we discussed
> earlier and setting up your own DNS cache, possibly with a whitelist
> for domains you want to send to the ISP forwarder.

Sure, and that's what I usually do. But if we can't specify that
behaviour for homenet, at least trying all upstream DNS servers gives a
better chance of finding one that works.

 Right, so if this is the case, how about we specify that routers MAY (or
 maybe even SHOULD) support MPvD-specific resolver addresses, and
 advertise the fact over HNCP. And that if a router receives such an
 announcement from another router it MUST announce the MPvD-specific
 resolver addresses over DHCP/RA. This way we ensure that *if* a router
 on the network implements MPvD it is going to work for the whole
 network; but routers can still opt to not implement the functionality
 itself if the implementer doesn't want to pay the implementation cost.
>>> 
>>> Can you describe for us what this implementation cost is that you want
>>> to avoid?
>> 
>> Can you describe for us how multiplying the number of resolvers by N (or
>> MxN if we follow your suggestion of running a full set of resolvers on
>> every router) is *not* going to incur a significant implementation and
>> debugability cost?
>
> It's just a bunch of ports/address pairs, with one thing listening on
> all of them, and using the port/address pair as a behavioral selector.
> I'm not going to say that it's zero effort, but it's not hard.
> Honestly, every home router right now has some kind of DNS proxy or
> DNS resolver in it; this is not a big change. Compared to, say,
> implementing HNCP or DNSSD, it's utterly trivial.

You may be right that hacking up a working prototype isn't that hard.
But the failure modes change from "the internet is down" or may "I
cannot access site A", to "site A is working every third attempt, except
it is entirely broken on device X" maybe even with an added "ah, but
it works on device X if I go into the kitchen".

Hmm, while writing this is occurred to me that it might make sense to
just export the ISP DNS server(s) directly in the MPvD-only RAs?

-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 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen  va escriure:
>> I think we are wandering off into nonsense territory here.   Have you
>> observed this sort of problem in the field?   If so, can you describe
>> what happened?   If not, why would we optimize for it?
> 
> If you consider flaky ISP DNS servers to be "nonsense" you are clearly
> more fortunate with your ISPs than me. And that's before even going into
> the DNS censorship issue; in my part of the world ISP DNS servers are
> broken *by design*.

In both of these cases, you are better off doing what we discussed earlier and 
setting up your own DNS cache, possibly with a whitelist for domains you want 
to send to the ISP forwarder.

>>> Right, so if this is the case, how about we specify that routers MAY (or
>>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>>> advertise the fact over HNCP. And that if a router receives such an
>>> announcement from another router it MUST announce the MPvD-specific
>>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>>> on the network implements MPvD it is going to work for the whole
>>> network; but routers can still opt to not implement the functionality
>>> itself if the implementer doesn't want to pay the implementation cost.
>> 
>> Can you describe for us what this implementation cost is that you want
>> to avoid?
> 
> Can you describe for us how multiplying the number of resolvers by N (or
> MxN if we follow your suggestion of running a full set of resolvers on
> every router) is *not* going to incur a significant implementation and
> debugability cost?

It's just a bunch of ports/address pairs, with one thing listening on all of 
them, and using the port/address pair as a behavioral selector.   I'm not going 
to say that it's zero effort, but it's not hard.   Honestly, every home router 
right now has some kind of DNS proxy or DNS resolver in it; this is not a big 
change.   Compared to, say, implementing HNCP or DNSSD, it's utterly trivial.

___
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:

>> Depending on the type of performance problem. If the performance problem
>> is general, yes. If it is specific to DNS, there's no reason to not use
>> the connection for other things; and the "send queries to all upstreams"
>> solution will automatically converge to use the best-performing upstream.
>
> I think we are wandering off into nonsense territory here.   Have you
> observed this sort of problem in the field?   If so, can you describe
> what happened?   If not, why would we optimize for it?

If you consider flaky ISP DNS servers to be "nonsense" you are clearly
more fortunate with your ISPs than me. And that's before even going into
the DNS censorship issue; in my part of the world ISP DNS servers are
broken *by design*.

>> Right, so if this is the case, how about we specify that routers MAY (or
>> maybe even SHOULD) support MPvD-specific resolver addresses, and
>> advertise the fact over HNCP. And that if a router receives such an
>> announcement from another router it MUST announce the MPvD-specific
>> resolver addresses over DHCP/RA. This way we ensure that *if* a router
>> on the network implements MPvD it is going to work for the whole
>> network; but routers can still opt to not implement the functionality
>> itself if the implementer doesn't want to pay the implementation cost.
>
> Can you describe for us what this implementation cost is that you want
> to avoid?

Can you describe for us how multiplying the number of resolvers by N (or
MxN if we follow your suggestion of running a full set of resolvers on
every router) is *not* going to incur a significant implementation and
debugability cost?

-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 15 ag 2017, a les 7:37, Toke Høiland-Jørgensen  va escriure:
> Erm, except when the suboptimal path does *not* have substantially worse
> performance for the duration of the session? CDNs are used for other
> things than Netflix...

Simple answer: don't wait five seconds.

> What are you basing this assessment on?

The prevalence of support for MPvD in existing hosts?

> Depending on the type of performance problem. If the performance problem
> is general, yes. If it is specific to DNS, there's no reason to not use
> the connection for other things; and the "send queries to all upstreams"
> solution will automatically converge to use the best-performing upstream.

I think we are wandering off into nonsense territory here.   Have you observed 
this sort of problem in the field?   If so, can you describe what happened?   
If not, why would we optimize for it?

> Right, so if this is the case, how about we specify that routers MAY (or
> maybe even SHOULD) support MPvD-specific resolver addresses, and
> advertise the fact over HNCP. And that if a router receives such an
> announcement from another router it MUST announce the MPvD-specific
> resolver addresses over DHCP/RA. This way we ensure that *if* a router
> on the network implements MPvD it is going to work for the whole
> network; but routers can still opt to not implement the functionality
> itself if the implementer doesn't want to pay the implementation cost.

Can you describe for us what this implementation cost is that you want to avoid?

___
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:

> El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen  va escriure:
>>> 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.
>
> Indeed.  However, it is never a lose.

Erm, except when the suboptimal path does *not* have substantially worse
performance for the duration of the session? CDNs are used for other
things than Netflix...

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

What are you basing this assessment on?

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

Well, I guess I'm not convinced that MPvD support is really required to
'make things work well'. But, well, if we can limit the complexity cost
I guess that becomes less of a problem.

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

Depending on the type of performance problem. If the performance problem
is general, yes. If it is specific to DNS, there's no reason to not use
the connection for other things; and the "send queries to all upstreams"
solution will automatically converge to use the best-performing upstream.

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

On this we are agreed, I think :)

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

Right, so if this is the case, how about we specify that routers MAY (or
maybe even SHOULD) support MPvD-specific resolver addresses, and
advertise the fact over HNCP. And that if a router receives such an
announcement from another router it MUST announce the MPvD-specific
resolver addresses over DHCP/RA. This way we ensure that *if* a router
on the network implements MPvD it is going to work for the whole
network; but routers can still opt to not implement the functionality
itself if the implementer doesn't want to pay the implementation cost.


-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 14 ag 2017, a les 16:21, Juliusz Chroboczek  va escriure:
> Now, the interaction between source-specific routing, BGP anycast, and
> multipath at the higher layers, that's an interesting topic to argue about.

I actually disagree, but it's beside the point, because this is a discussion 
about the homenet naming architecture. :)

___
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 14:25, Toke Høiland-Jørgensen  va escriure:
>> 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.

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.

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

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

[Juliusz Chroboczek]

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

I think that's an important point, and one that Ted didn't adequately
address in his reply.

-- Juliusz

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

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

[Juliusz Chroboczek]

> Why do you think CDNs exist? What would happen if every home network suddenly
> stopped using the technology that makes CDNs work?

I thought I'd just mention that split-horizon DNS is just one possible
technique.  BGP anycast is another one.  (AFAIK, Akamai use split-horizon
DNS while Cloudflare use BGP anycast.  No idea about Netflix.)

Now, the interaction between source-specific routing, BGP anycast, and
multipath at the higher layers, that's an interesting topic to argue about.

-- Juliusz

___
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:

> 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

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

[Ted Lemon]

El 12 ag 2017, a les 13:45, Michael Richardson  va 
escriure:
> I agree.  It seems like it ought to be a routing protocol at the edge, that
> the destinations involved should be advertised with longer prefixes, and with
> some kind of metric that implies the cost.  The edge routers that hear this
> should be skeptical, but should provide the information to the user.
> (The CAPPORT protocol and API would be useful here!)

The problem with this is that it is quite brittle—it depends on everything 
working right.   The routing has to be set up right.   The operator has to set 
the routing up right.   The other operator has to not deliberately or 
accidentally set the routing up wrong.   The home network has to successfully 
get the right routing information and use it correctly.

> 
>mcr> It seems to me that we are re-inventing SHIM6, trying in vain to
>mcr> pretend wenever heard of that. And I still don't understand why it
>mcr> was killed.
> 
>> Shim6 attempts to solve a much larger problem, and in a rather heavyweight
>> and top-down way.
> 
> I view MPvD as being as being heavier weight, involving changes to more parts
> of the host stack, with poorer results.

It might be worth actually writing down why you think that's so.   It's far 
from obvious to me that it is, but I am not as familiar as you are with Shim6.  
 Unfortunately as far as I know nobody ever presented anything about Shim6 in 
MIF; if in fact what you are saying is true, a lot of time and effort could 
have been saved if that had happened.

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

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

[Michael Richardson]

Ted Lemon  wrote:
> On Aug 11, 2017, at 12:53 PM, Michael Richardson 
> wrote:

mcr> The example that, in contrast to all other content, is when content
mcr> is zero-rated via 3G but not via WIFI. (generalized to any two
mcr> uplinks) I don't know the source address selection or source routing
mcr> can deal with that problem period.

> Two points here. First of all, does the IETF want to support zero-rating 
on a
> technological level? I guess we're somewhat agnostic about it, but I 
would be
> resistant to spending cycles on it unless somebody is really energized 
about
> it. It seems to me that if you have zero-rating, you have a problem.

In one of the original homenet architecture usage scenarios we have IPTV
being provided over a seperate DSL connection over IPv6, but which did not
provide general IPv6 connectivity.  This was from Japan, I believe.

That's actually an easier situation, since the connection won't work at all
if an application uses the wrong source address.  I suggested in:
   https://datatracker.ietf.org/doc/draft-richardson-homenet-secret-gardens/

which I wrote hurriedly when I understand what MIF was doing (but really it
was too late).  I feel that a lot of MIF's problem statement was tied up with
existing operators apply IPv4 think to IPv6.

> That said, I certainly agree with you that MPvD doesn't solve this 
problem.
> The general attitude with MPvD is that when you have multiple provisioning
> domains, it's not necessarily the case that you can believe the claims 
that
> one provider or the other makes. If you want to zero-rate, the person 
who's
> going to be paying for it when the zero-rating doesn't happen is going to 
be
> responsible for making sure that it's configured correctly. If the person 
who
> makes the money is responsible for configuring it, they are going to
> configure it in a way that serves their interests, not the user's
> interests.

In the debate in Canada over this (where N=Bell Canada, who owns CTV), two
things seem to occur:
  a) if one is a customer of ISP N, then you use XYZ app on your phone, you
 get access to content Q. It's free because your relationship with N.
 If you are N's network, then usage fees that would normally occur are
 waved.  If you are not on N's 3G network, but on WIFI (or some other
 provider), your credentials get you access, but you might pay via that
 other path.
 The MPvD required to happen can happen in the XYZ app, and actually the
 entire ecosystem is a walled garden.

  b) as a bonus for having play PQRT, when on ISP's N's network, then your
 traffic to third party B is free. (Typical example is Spotify)
 You can use *ANY* app you like to access the content.

> What MPvD _does_ do in addressing this problem is that it provides a 
context
> in which special-casing for zero-rating can be effectively configured.
> Without MPvD or something like it, it's actually impossible to support
> zero-rating, even if you think that's a desirable thing to do.

I agree that it may be required. I am suggesting that it's not sufficient on
it's own.  You can only get situation (a) above, not situation (b).

> If we were to support zero-rating, the way I would propose that we do it 
is
> to specify a way that a provider can advertise the availability of
> zero-rating for some set of products, and the user can choose to accept or
> not accept that advertising in a convenient way, rather than having to
> manually configure a whitelist. But don't get me started on the 
opportunities
> for trouble that this idea presents.

I agree.  It seems like it ought to be a routing protocol at the edge, that
the destinations involved should be advertised with longer prefixes, and with
some kind of metric that implies the cost.  The edge routers that hear this
should be skeptical, but should provide the information to the user.
(The CAPPORT protocol and API would be useful here!)

mcr> It seems to me that we are re-inventing SHIM6, trying in vain to
mcr> pretend wenever heard of that. And I still don't understand why it
mcr> was killed.

> Shim6 attempts to solve a much larger problem, and in a rather heavyweight
> and top-down way.

I view MPvD as being as being heavier weight, involving changes to more parts
of the host stack, with poorer results.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Tim Chown]

> On 11 Aug 2017, at 17:53, Michael Richardson  wrote:
> 
> Ted Lemon  wrote:
>> 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.
> 
> My problem with the MPVD solution is that it seems incomplete too.
> 
> The example that, in contrast to all other content, is when content is
> zero-rated via 3G but not via WIFI. (generalized to any two uplinks)
> I don't know the source address selection or source routing can deal with
> that problem period.
> 
> It seems to me that we are re-inventing SHIM6, trying in vain to pretend we
> never heard of that.  And I still don't understand why it was killed.

Extension headers.

> But, again, I want to adopt the document so that we can argue about this
> as part of our charter work.

Indeed! 

Tim

___
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]

On Aug 11, 2017, at 12:53 PM, Michael Richardson  wrote:
> The example that, in contrast to all other content, is when content is
> zero-rated via 3G but not via WIFI. (generalized to any two uplinks)
> I don't know the source address selection or source routing can deal with
> that problem period.

Two points here.   First of all, does the IETF want to support zero-rating on a 
technological level?   I guess we're somewhat agnostic about it, but I would be 
resistant to spending cycles on it unless somebody is really energized about 
it.   It seems to me that if you have zero-rating, you have a problem.

That said, I certainly agree with you that MPvD doesn't solve this problem.   
The general attitude with MPvD is that when you have multiple provisioning 
domains, it's not necessarily the case that you can believe the claims that one 
provider or the other makes.   If you want to zero-rate, the person who's going 
to be paying for it when the zero-rating doesn't happen is going to be 
responsible for making sure that it's configured correctly.   If the person who 
makes the money is responsible for configuring it, they are going to configure 
it in a way that serves their interests, not the user's interests.

What MPvD _does_ do in addressing this problem is that it provides a context in 
which special-casing for zero-rating can be effectively configured.   Without 
MPvD or something like it, it's actually impossible to support zero-rating, 
even if you think that's a desirable thing to do.

If we were to support zero-rating, the way I would propose that we do it is to 
specify a way that a provider can advertise the availability of zero-rating for 
some set of products, and the user can choose to accept or not accept that 
advertising in a convenient way, rather than having to manually configure a 
whitelist.   But don't get me started on the opportunities for trouble that 
this idea presents.

> It seems to me that we are re-inventing SHIM6, trying in vain to pretend we
> never heard of that.  And I still don't understand why it was killed.

Shim6 attempts to solve a much larger problem, and in a rather heavyweight and 
top-down way.


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

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

[Michael Richardson]

Ted Lemon  wrote:
> 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.

My problem with the MPVD solution is that it seems incomplete too.

The example that, in contrast to all other content, is when content is
zero-rated via 3G but not via WIFI. (generalized to any two uplinks)
I don't know the source address selection or source routing can deal with
that problem period.

It seems to me that we are re-inventing SHIM6, trying in vain to pretend we
never heard of that.  And I still don't understand why it was killed.

But, again, I want to adopt the document so that we can argue about this
as part of our charter work.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
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]

On Aug 11, 2017, at 12:07 PM, Juliusz Chroboczek  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

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

[Ted Lemon]

On Aug 11, 2017, at 9:27 AM, Juliusz Chroboczek  wrote:
> Can we please agree that this document has no business mandating 
> round-robining?

The point of the text on round-robining is to avoid a situation where one 
provider's answers wind up being preferred over another provider's because of a 
difference in the number of recursive resolvers they offer.   I wrote it the 
way I did because the mental model for how to do it that sprang into my mind 
when I was writing it was the round robin model.

I don't have a strong preference for that model, although I think in practice 
it works, particularly if you take a happy eyeballs approach to it rather than 
timing out before switching.   That is, you don't ask all resolvers at 
_exactly_ the same time: you ask one first, and give it enough time that if 
it's operating in spec, you will get an answer before you ask the next one, but 
you ask the next one long before the query to the first one has timed out.

The bottom line is that this is an implementation detail, and I think you are 
right that it should not be specified the way it currently is.

___
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]

On Aug 11, 2017, at 9:09 AM, Toke Høiland-Jørgensen  wrote:
> Because I'm not convinced the added implementation complexity is worth
> it; so yeah, the last one I guess...

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.   That's not the charter of this working group.   The 
reason we chartered this working group was _explicitly_ to study the problem 
carefully, to see what we needed to do to solve it well, to describe what that 
was, and to do it.

My experience both in doing math when I was a math student, and in doing 
computer science now that I'm a computer geek, is that often times a shortcut 
solution to a real problem winds up being harder than a good solution in the 
long run.   Sure, you saved a little time with that shortcut, but the long term 
result was that you didn't actually solve the problem, and now you have a brick 
that you have to fix in-place, instead of a green field where you can do what 
needs to be done without continuing to support the old solution.

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?

As for the MPvD problem, you say that you'd like to avoid the complexity, but 
have you actually explored what the complexity looks like?   Have you asked the 
Android folks and the Apple folks why they are interested in (and in some 
cases, already have) put support for this into their devices?

I've attached a picture of the router I'm using for my development work on this 
(the second, really tiny board is the serial console interface I'm using to 
debug).   It's got 8G of flash, 2G of RAM, a 1.2G 4-core arm64 CPU, gigabit 
ethernet and a fast I/O bus for both wired and wireless network interfaces.   
It cost me US$24.99.   This is more than capable of supporting the complexity 
we are talking about, which I don't think is really that much complexity anyway.

Are you targeting a cheaper, less capable device than this?   If so, can you 
talk about why you think that's important for Homenet?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[STARK, BARBARA H]

> From: Ted Lemon
> Barbara, I seem to recall that you were enthusiastic about the work when it 
> was discussed in the meeting.   You're allowed to be one of the people who's 
> in favor of it, despite being chair.   Indeed, as > chair, you can just adopt 
> it by fiat if you want.   I actually agree with Ray and Michael that Juliusz 
> reasoning was flawed, and am definitely in favor of adopting it and working 
> on it.   I also agree with 
> Andrew that it shouldn't be the final word on naming in the homenet.

Here are my non-chair thoughts.
I do think there is value in defining a home network naming / DNS architecture. 
I (enthusiastically) support adoption of the concept.
The non-boilerplate part of the table of contents is about "Name Resolution", 
with headers for "Configuring Resolvers", "Configuring Service Discovery", 
"Resolution of local names", "DNSSEC Validation", "Support for Multiple 
Provisioning Domains", "Using the Local Namespace While Away From Home". I 
support these as a good initial set of headers for a table of contents.
I don't like requiring DNS proxy in all homenet routers and would like to 
explore other options. But the DNS resolver does have to be somewhere in the 
premises.
I'd like to actually explore what we could for DNSSEC in the context of some 
holistic home network "key" architecture, and maybe we could discuss some more 
even while agreeing it's out of scope for this doc. 
I agree with scoping to internal resolution and not dealing with external 
resolution. But I recognize others might want to discuss more.
I fully agree with this being a separate "provisioning domain", but I'm not 
fully convinced the proposed solution is the right one. 

Conclusion: As long as we can keep discussion alive and healthy, and not go to 
WGLC prematurely, I'm in favor of adoption.
The main reason I hesitated to lend support is from bad experience in other 
groups where authors have tried to object to comments on the basis of "you 
supported adoption, this text was in the draft when it was adopted, and you 
didn't object to this text prior to adoption". But so long as the chairs don't 
tolerate this sort of attitude, I think we'll be fine. BTW, I've never seen 
that attitude from Ted or Daniel. And I have confidence in the chairs' ability 
to be intolerant.

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

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

[Juliusz Chroboczek]

>>> DNS resolvers use round-robining. That's how the protocol works.

>> Does that mean that dnsmasq breaks the protocol?

>> 
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366

> What dnsmasq seems to be doing is trying all servers at once. That would work
> too, if the pattern described in the document is followed.

Ted,

Can we please agree that this document has no business mandating round-robining?

-- Juliusz

___
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:

> Why do you want it to be optional?  What problem are you trying to solve?
> Do you not know how to do it?  Do you think it's resource intensive? Do you
> think it reduces reliability more than not doing it?

Because I'm not convinced the added implementation complexity is worth
it; so yeah, the last one I guess...

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

Why do you want it to be optional?  What problem are you trying to solve?
Do you not know how to do it?  Do you think it's resource intensive? Do you
think it reduces reliability more than not doing it?

On Aug 11, 2017 8:55 AM, "Toke Høiland-Jørgensen"  wrote:

> Ted Lemon  writes:
>
> > How does the client know in which PvD a response is intended to exist.
>
> Well, in some cases normal source address selection rules are going to
> do the trick (i.e., the client picks the source address closest to the
> destination). In others it won't, and the client will get degraded
> behaviour.
>
> > Also, what problem are you trying to solve here? What you described
> > sounds like it's just an attempt at implementing mpvd on a homenet
> > without requiring that all routers behave the same.
>
> Well, as I said I would be perfectly happy to just ignore the MPvD issue
> entirely. What I'm trying to do is at least make it optional for a
> homenet router to implement it... :)
>
> -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:

> How does the client know in which PvD a response is intended to exist.

Well, in some cases normal source address selection rules are going to
do the trick (i.e., the client picks the source address closest to the
destination). In others it won't, and the client will get degraded
behaviour.

> Also, what problem are you trying to solve here? What you described
> sounds like it's just an attempt at implementing mpvd on a homenet
> without requiring that all routers behave the same.

Well, as I said I would be perfectly happy to just ignore the MPvD issue
entirely. What I'm trying to do is at least make it optional for a
homenet router to implement it... :)

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

What dnsmasq seems to be doing is trying all servers at once. That would
work too, if the pattern described in the document is followed.

On Aug 11, 2017 8:41 AM, "Juliusz Chroboczek"  wrote:

> > - round-robin = bad (think why happy eyeballs came up for example of
> why)
>
> > DNS resolvers use round-robining. That's how the protocol works.
>
> Does that mean that dnsmasq breaks the protocol?
>
>   http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=
> f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366
>
> -- Juliusz
>
___
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]

Juliusz Chroboczek  writes:

>> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
>> all queries to router A, using a source address in the same prefix
>> as the original request was received from.
>
>> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
>> router A's address (which would need to be routable inside the
>> homenet, obviously) as the DNS server in RAs.
>
> This has the significant advantage of not requiring a DNS proxy on each
> Homenet router.  It has the disadvantage of not requiring a DNS proxy on
> each Homenet router.
>
> I like it.
>
> (Aside: what's the fallback mode if there's no A in the network?  One
> could either advertise all of the ISPs' DNS servers in RAs, or advertise
> oneself notwithstanding no support for MPvD.  I guess both should be
> allowed.)

Yeah, or fallback to 2 (send queries to all upstreams and reply with the
union to the client). If you don't want to bother being MPvD-aware, you
just set N (the number of upstreams to wait for) to 1, and it turns into
a sort of happy eyeballs for DNS...

> (Second aside: what happens when there are multiple As in the network?
> One could either elect the "master" DNS server, so that all links use the
> same DNS proxy, or let each router pick one at random, so you get load
> balancing.  I guess only one should be allowed.)

I'd say don't bother with an election. All routers with the capability
are eligible as upstreams. Picking one at random is probably fine, but
not sure if we need to specify that? "Pick the first one you see" would
probably also work, as long as you update your choice if that router
goes away...

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

How does the client know in which moved a response is intended to exist.
Also, what problem are you trying to solve here?  What you described sounds
like it's just an attempt at implementing mpvd on a homenet without
requiring that all routers behave the same.

On Aug 11, 2017 6:15 AM, "Toke Høiland-Jørgensen"  wrote:

> Ted Lemon  writes:
>
> > On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen 
> wrote:
> >> Now, assuming that I am wrong and this is actually a serious issue that
> >> we need to solve (of which I am not opposed to being convinced), I think
> >> it would be feasible to come up with a solution where we could at least
> >> allow less capable routers that do not implement the full MPvD support.
> >> I can think of at least two ways off the top of my head:
> >>
> >> 1. Allow the router in question to offload queries to a more capable
> >>   router elsewhere in the homenet.
> >>
> >> 2. Allow the router in question to just query all upstreams and combine
> >>   the results (and so offload the problem to the client).
> >
> > Great.   Can you explain, step by step, how to do either of these
> > things?
>
> Given that router A supports MPvD and router B doesn't:
>
> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
> all queries to router A, using a source address in the same prefix
> as the original request was received from.
>
> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
> router A's address (which would need to be routable inside the
> homenet, obviously) as the DNS server in RAs.
>
> 2. Router B simultaneously forwards the query to all upstream DNS
>servers known to the homenet, waits for replies from N of them,
>creates the union set of all those replies and sends that back to the
>client.
>
> If N=1 in 2, that corresponds to just ignoring MPvD. Router B could also
> fall back to 2 if no router A is available on the network.
>
> Now, please feel free to explain why you think these would break
> things... ;)
>
> -Toke
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ray Bellis]

On 11/08/2017 13:40, Juliusz Chroboczek wrote:

>> DNS resolvers use round-robining. That's how the protocol works.
> 
> Does that mean that dnsmasq breaks the protocol?

AFAICR, that's one of those niggly parts of the DNS protocol that is not
strictly specified.

Ray

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

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

[Juliusz Chroboczek]

> - round-robin = bad (think why happy eyeballs came up for example of why)

> DNS resolvers use round-robining. That's how the protocol works.

Does that mean that dnsmasq breaks the protocol?

  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/forward.c;h=f22556a595673c7478706f17a22af2095e1068f8;hb=HEAD#l366

-- Juliusz

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

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

[Juliusz Chroboczek]

> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards
> all queries to router A, using a source address in the same prefix
> as the original request was received from.

> 1b. Router A exports over HNCP that it supports MPvD. Router B uses
> router A's address (which would need to be routable inside the
> homenet, obviously) as the DNS server in RAs.

This has the significant advantage of not requiring a DNS proxy on each
Homenet router.  It has the disadvantage of not requiring a DNS proxy on
each Homenet router.

I like it.

(Aside: what's the fallback mode if there's no A in the network?  One
could either advertise all of the ISPs' DNS servers in RAs, or advertise
oneself notwithstanding no support for MPvD.  I guess both should be
allowed.)

(Second aside: what happens when there are multiple As in the network?
One could either elect the "master" DNS server, so that all links use the
same DNS proxy, or let each router pick one at random, so you get load
balancing.  I guess only one should be allowed.)

-- Juliusz

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

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

[Ray Bellis]

On 11/08/2017 12:59, Juliusz Chroboczek wrote:

> In simple terms, I said "Why don't we try implementing bits of this
> document before we adopt".  I never said "We need seven interoperable
> independent implementations before adoption".

Juliusz,

IMNSHO, that's still too high a bar.

kind regards,

Ray



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

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

[Juliusz Chroboczek]

> Juliusz expressed opposition to adoption, but Ray and Michael said the
> reasoning for objection was flawed (that Juliusz was setting the bar too
> high and the procedural objections were not valid in the context of IETF
> procedures).

I probably expressed myself badly -- my objections were technical, not
procedural.

In simple terms, I said "Why don't we try implementing bits of this
document before we adopt".  I never said "We need seven interoperable
independent implementations before adoption".

-- Juliusz

___
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:

> On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen  wrote:
>> Now, assuming that I am wrong and this is actually a serious issue that
>> we need to solve (of which I am not opposed to being convinced), I think
>> it would be feasible to come up with a solution where we could at least
>> allow less capable routers that do not implement the full MPvD support.
>> I can think of at least two ways off the top of my head:
>> 
>> 1. Allow the router in question to offload queries to a more capable
>>   router elsewhere in the homenet.
>> 
>> 2. Allow the router in question to just query all upstreams and combine
>>   the results (and so offload the problem to the client).
>
> Great.   Can you explain, step by step, how to do either of these
> things?

Given that router A supports MPvD and router B doesn't:

1a. Router A exports over HNCP that it supports MPvD. Router B forwards
all queries to router A, using a source address in the same prefix
as the original request was received from.

1b. Router A exports over HNCP that it supports MPvD. Router B uses
router A's address (which would need to be routable inside the
homenet, obviously) as the DNS server in RAs.

2. Router B simultaneously forwards the query to all upstream DNS
   servers known to the homenet, waits for replies from N of them,
   creates the union set of all those replies and sends that back to the
   client.

If N=1 in 2, that corresponds to just ignoring MPvD. Router B could also
fall back to 2 if no router A is available on the network.

Now, please feel free to explain why you think these would break
things... ;)

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

On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen  wrote:
> Now, assuming that I am wrong and this is actually a serious issue that
> we need to solve (of which I am not opposed to being convinced), I think
> it would be feasible to come up with a solution where we could at least
> allow less capable routers that do not implement the full MPvD support.
> I can think of at least two ways off the top of my head:
> 
> 1. Allow the router in question to offload queries to a more capable
>   router elsewhere in the homenet.
> 
> 2. Allow the router in question to just query all upstreams and combine
>   the results (and so offload the problem to the client).

Great.   Can you explain, step by step, how to do either of these things?

___
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:

> On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen  wrote:
>> with the possible exception of the
>> requirement for supporting multiple provisioning domains
>
> How would you solve the problem of dual-homing without the multiple
> provisioning domain support described in the document?

We're talking about the "oh no, my netflix streams is coming from the
wrong ISP" kind of problem here, right? I.e., same DNS request gives
different answer depending on which ISP I send it to?

For one thing, I'm not convinced this is that big of a problem. I happen
to live in a country that likes to apply censorship by messing with DNS;
so I generally don't use my ISP's name servers, and have never had any
issues arising from this. So in this case a solution could just be to
ignore the issue... :)

Now, assuming that I am wrong and this is actually a serious issue that
we need to solve (of which I am not opposed to being convinced), I think
it would be feasible to come up with a solution where we could at least
allow less capable routers that do not implement the full MPvD support.
I can think of at least two ways off the top of my head:

1. Allow the router in question to offload queries to a more capable
   router elsewhere in the homenet.

2. Allow the router in question to just query all upstreams and combine
   the results (and so offload the problem to the client).


-Toke

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

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

[Markus Stenberg]

On 10 Aug 2017, at 23.33, STARK, BARBARA H  wrote:
> 
> With one day left in CFA for draft-tldm-simple-homenet-naming, here is my 
> summary of what I think I've read.
> 
> Exactly 3 people have expressed support for adoption (Daniel [author], 
> Michael R, James). Hmm. That's not a lot.
> 
> Juliusz expressed opposition to adoption, but Ray and Michael said the 
> reasoning for objection was flawed (that Juliusz was setting the bar too high 
> and the procedural objections were not valid in the context of IETF 
> procedures). Ray said the purpose of a CFA is "to get agreement that a 
> document is an appropriate direction for the WG to explore, even if it might 
> require substantial work".
> Ted [author] said he thought it might be reasonable to put the CFA on hold 
> until Daniel did another update.
> Tim C said he thought it was early for adoption (for this and related dnssd 
> drafts).
> 
> I hope I got this summary right. Did I miss anything important?
> Does anyone else have an opinion? Does anyone who has expressed an opinion 
> want to express a new and different opinion?

I find it desirable that a work in this direction goes on. However, there’s 
details due to which I am not very keen about this particular document (or the 
related dns-sd documents for that matter, but this is not the forum for those). 
In order I encountered them during a browse through the document:

- requiring every link on every router to have local DNS forwarder/server seems 
very broken to me. _one_ in-home DNS server is probably enough.
 ( external dns update could be prevented also by e.g. knowing prefix(es) 
allocated to homenet, by using ULA, or by judicious firewalling; I prefer ULA 
but YMMV )

- 3.3
 - it implies that homenet exposes DNS outside home (by default?) and uses 
instead custom dns server logic to handle .home.arpa from ‘outside’; why not 
just firewall it and be done with it (or listen only on e.g. ULA prefix)
 - why filter out global IPs?

- 3.5 (PVD madness)
 - WHY? can’t we get just rid of split horizon DNS madness and use _a_ DNS 
instead of N DNS servers?
 - round-robin = bad (think why happy eyeballs came up for example of why)

I’d much rather see some detail on how selected subset of services can be 
exposed outside home (including also how related firewalling works), than the 
PVD stuff, and some of the things seem just misguided from implementation point 
of view; a set of DNS forwarders/servers seems like overkill if one is 
implementing N+1 device (which assumes there is ’smarter’ router already in the 
home, look at the current mesh wireless solutions for example).

Anyway, this is my yearly post quota used for the WG, I’ll be back in 2018 :) 
Looking forward to using this someday, but given it requires host changes 
(notably parts of 3.3 and 3.5), I am not holding my breath on that yet.

Cheers,

-Markus

___
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]

On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen  wrote:
> with the possible exception of the
> requirement for supporting multiple provisioning domains

How would you solve the problem of dual-homing without the multiple 
provisioning domain support described in the document?

___
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]

Andrew Sullivan  writes:

> On Thu, Aug 10, 2017 at 08:33:11PM +, STARK, BARBARA H wrote:
>> Does anyone else have an opinion? Does anyone who has expressed an opinion 
>> want to express a new and different opinion?
>> Barbara
>
> I haven't weighed in because I can't make up my mind.
>
> On the one hand, I think this is a reasonable and limited set of
> things to do to get started with, and so I'd normally say we should
> adopt it and go ahead.
>
> On the other hand, as I suggested in Prague, it's quite a limited set
> of aspirations, and quite a bit short of what we had originally
> suggested we were trying to do. It even seems shy of various claims in
> the architecture document, which I see as a sort of requirements
> document.

I am in a bit of the same boat. I think most of the things in the
document are reasonable things to do (with the possible exception of the
requirement for supporting multiple provisioning domains), but I would
also like to solve some of the other problems that are deemed out of
scope in the current version of the document. At a minimum, I would like
to solve the "services should be visible from the outside" problem.

I guess I'm fine with adopting the document, as long as it's still
possible to make these kinds of adjustments in scope further along the
way... :)

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

Barbara, I seem to recall that you were enthusiastic about the work when it
was discussed in the meeting.   You're allowed to be one of the people
who's in favor of it, despite being chair.   Indeed, as chair, you can just
adopt it by fiat if you want.   I actually agree with Ray and Michael that
Juliusz reasoning was flawed, and am definitely in favor of adopting it and
working on it.   I also agree with Andrew that it shouldn't be the final
word on naming in the homenet.

On Thu, Aug 10, 2017 at 4:38 PM, Andrew Sullivan 
wrote:

> On Thu, Aug 10, 2017 at 08:33:11PM +, STARK, BARBARA H wrote:
> > Does anyone else have an opinion? Does anyone who has expressed an
> opinion want to express a new and different opinion?
> > Barbara
>
> I haven't weighed in because I can't make up my mind.
>
> On the one hand, I think this is a reasonable and limited set of
> things to do to get started with, and so I'd normally say we should
> adopt it and go ahead.
>
> On the other hand, as I suggested in Prague, it's quite a limited set
> of aspirations, and quite a bit short of what we had originally
> suggested we were trying to do.  It even seems shy of various claims
> in the architecture document, which I see as a sort of requirements
> document.
>
> So, I'm not opposed to working on it.  But I wish it were more
> ambitious.  But I wish I were more ambitious, too :-)
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Andrew Sullivan]

On Thu, Aug 10, 2017 at 08:33:11PM +, STARK, BARBARA H wrote:
> Does anyone else have an opinion? Does anyone who has expressed an opinion 
> want to express a new and different opinion?
> Barbara

I haven't weighed in because I can't make up my mind.

On the one hand, I think this is a reasonable and limited set of
things to do to get started with, and so I'd normally say we should
adopt it and go ahead.

On the other hand, as I suggested in Prague, it's quite a limited set
of aspirations, and quite a bit short of what we had originally
suggested we were trying to do.  It even seems shy of various claims
in the architecture document, which I see as a sort of requirements
document.

So, I'm not opposed to working on it.  But I wish it were more
ambitious.  But I wish I were more ambitious, too :-)

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

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

[STARK, BARBARA H]

With one day left in CFA for draft-tldm-simple-homenet-naming, here is my 
summary of what I think I've read.

Exactly 3 people have expressed support for adoption (Daniel [author], Michael 
R, James). Hmm. That's not a lot.

Juliusz expressed opposition to adoption, but Ray and Michael said the 
reasoning for objection was flawed (that Juliusz was setting the bar too high 
and the procedural objections were not valid in the context of IETF 
procedures). Ray said the purpose of a CFA is "to get agreement that a document 
is an appropriate direction for the WG to explore, even if it might require 
substantial work".
Ted [author] said he thought it might be reasonable to put the CFA on hold 
until Daniel did another update.
Tim C said he thought it was early for adoption (for this and related dnssd 
drafts).

I hope I got this summary right. Did I miss anything important?
Does anyone else have an opinion? Does anyone who has expressed an opinion want 
to express a new and different opinion?
Barbara




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