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

[homenet] homenet - New Meeting Session Request for IETF 100

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Barbara Stark, a Chair 
of the homenet working group.


-
Working Group Name: Home Networking
Area Name: Internet Area
Session Requester: Barbara Stark

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: v6ops intarea dnsop dnssd 6man babel saag tls
 Second Priority: mptcp lpwan



People who must be present:
  Stephen Farrell
  Terry Manderson
  Ray Bellis
  Barbara Stark

Resources Requested:

Special Requests:
  
-

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

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