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

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 10 Aug 2017 20:33:11 +0000

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Aug 2017 16:38:43 -0400

> Does anyone else have an opinion? Does anyone who has expressed an opinion want to express a new and different opinion?

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
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2017 16:49:12 -0400

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 <[email-masked]>
wrote:

> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 10 Aug 2017 23:07:22 +0200

Andrew Sullivan <[email-masked]> writes:

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2017 17:22:53 -0400

On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen <[email-masked]> 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?

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 11 Aug 2017 00:48:18 +0300

> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2017 17:59:00 -0400

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

No, it doesn't say that.

> - why filter out global IPs?

Because if you don't, then when you lose your global prefix, you lose access to your printer.

> - WHY? can’t we get just rid of split horizon DNS madness and use _a_ DNS instead of N DNS servers?

If you tell me how to implement that, I will be excited.   Otherwise, not solving this problem will produce brokenness.   The simplest way to solve it is to have the network advertise only one external prefix on the homenet if the homenet is multiply-homed.   Is that your preferred solution?

Also, this isn't necessarily split-horizon madness.   It's valid for the same query to yield different answers; this is operationally normal, and trying to do something to stop it in homenet isn't going to work.   Like you, I would prefer to do CDNs in a way that doesn't involve all of this brokenness, but if you want to watch Netflix on your homenet, we need to make this work.

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

DNS resolvers use round-robining.   That's how the protocol works.   I can think of ways to improve on that, but they all involve changing the DNS packet format.   So I don't think that's in scope.   The draft just specifies how DNS round robining should work in the context of mpvd on a homenet—it didn't invent it.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 11 Aug 2017 00:07:50 +0200

Ted Lemon <[email-masked]> writes:

> 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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Aug 2017 20:02:46 -0400

> - WHY? can’t we get just rid of split horizon DNS madness and use _a_ DNS instead of N DNS servers?

I am not happy with PVD stuff either, but it's not enough to block the
document.  Rather, I want to adopt it so that we discuss this.
I understand we have to adopt the PVD document too.

    > 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

ha.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Aug 2017 20:32:58 -0400

>   the results (and so offload the problem to the client).

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 11 Aug 2017 12:15:39 +0200

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

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 11 Aug 2017 13:59:16 +0200

> 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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 11 Aug 2017 13:01:02 +0100

> independent implementations before adoption".

Juliusz,

IMNSHO, that's still too high a bar.

kind regards,

Ray

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 11 Aug 2017 14:13:08 +0200

>     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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 11 Aug 2017 14:40:54 +0200

> 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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 11 Aug 2017 13:42:31 +0100

> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 08:46:45 -0400

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.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 11 Aug 2017 14:48:17 +0200

> oneself notwithstanding no support for MPvD.  I guess both should be

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 08:50:39 -0400

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" <[email-masked]> wrote:

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 11 Aug 2017 14:55:57 +0200

Ted Lemon <[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 09:03:08 -0400

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?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 11 Aug 2017 15:09:51 +0200

> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 11 Aug 2017 15:27:02 +0200

> 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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 11 Aug 2017 13:32:02 +0000

> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 09:34:43 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 10:44:15 -0400

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 11 Aug 2017 18:07:17 +0200

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

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

> Are you targeting a cheaper, less capable device than this? If so, can
> you talk about why you think that's important for Homenet?

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.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 12:35:09 -0400

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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Aug 2017 12:53:37 -0400

Ted Lemon <[email-masked]> 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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Aug 2017 13:10:22 -0400

> I don't know the source address selection or source routing can deal with

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.

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

---

From: Tim Chown <[email-masked]>
Date: Fri, 11 Aug 2017 17:47:03 +0000

> On 11 Aug 2017, at 17:53, Michael Richardson <[email-masked]> wrote:
> 

Extension headers.

> as part of our charter work.

Indeed! 

Tim

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Aug 2017 13:45:13 -0400

> On Aug 11, 2017, at 12:53 PM, Michael Richardson <[email-masked]>

    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

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Aug 2017 15:21:41 -0400

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

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Aug 2017 20:09:25 -0400

{new subject line, nuked References}

Ted Lemon <[email-masked]> wrote:
    > 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.

This seems a bit like FUD: the Internet depends upon all sorts of "brittle" things
like "not deliberately or accidentially" setting up the routing wrong.
I do agree that a malicious operator could pretend to zero-rate things and
then make it actually impossible to ever get that service.

But: MPvD seems to depend upon the same kind of brittle things!!!

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

MIF tried to solve all sorts of IPv4-induced problems that marketing people
thought that they had.  Many were not well defined in my opinion, or in my
opinion were not even good ideas.

Tim points out that SHIM6 was undeployable as described because of extension
headers; but I was never convinced that was what killed it, but okay.
(I believe that was the year I dealt with family illnesses)
Maybe in the end, we have LISP as a response?

SHIM6 tries to deal with multi-homing by proposing incrementally deployable
changes to hosts.  Host (pairs) that have it, benefit without infrastructure
in between being upgraded.
A host that had SHIM6, and had some HNCP and/or minimal babel listening,
would be able to intelligently do SHIM6 better.
I think that SHIM6 would also provide a channel by which a service provider
who had differential rates for different access channels to say such a thing
through the SHIM6 layer. (That would be an extension)

MPvD tries to do the same thing: avoid making any changes to the
infrastructure outside of the "device" (in the telco's case, a smartphone
that they have an agreement with the manufacturer to modify, that they lock
and "sell").

HOMENET is chartered to fix the infrastructure *in the home* such that
unmodified hosts can reasonably get basic services without changes.

MPvD only works when the end host has multiple interfaces that it can
actually provision from, *or* if we have virtual provisioning domains on the
same link! i.e. infrastructure!  Which we do have in HOMENET.

At which point MPvD requires that the infrastructure and the host cooperate
to communicate the multiple domains to the end host via the infrastructure.

That's where all the "brittle" things you describe show up!!!
MPvD requires the walled-garden ISPs to do the same configuration.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Aug 2017 22:36:04 -0400

> like "not deliberately or accidentially" setting up the routing wrong.

I get that, and it's possible that MPvD is the wrong answer here.   However, I think we need to actually analyze the problem and not just theorize about it at this level.   The reason that the MPvD work happened was that there was a need for it; it may not have been the right way to solve the problem, but I'm having trouble figuring out how LISP or Shim6 improves the situation.

The problem is simply that it needs to be the case that if a host looks up a name from one ISP's name servers, then it needs to use that ISP's prefix to contact the address that it gets from the lookup; if it uses the other ISP's name servers, then it needs to use that ISP's prefix.   Otherwise CDNs fail.

The other problems that you are talking about are also worth thinking about, but we haven't looked at them in this amount of detail.

But one thing to remember is that there's a reason why it's beneficial for hosts to implement MPvD; this is handset vendors implement it it.   It neatly wraps up real problems that real hosts have, pretty much orthogonally to whether IPv4 or IPv6 (or both) are in use.   Given that this is the case, part of the benefit of using it in the homenet is that we'd be using existing logic in hosts.

But if you really think Shim6 or LISP solve the problem better, one exercise that you might want to try is answering the question, "how does Shim6 help me with the CDN problem?   How does LISP help me with the CDN problem.   What do I have to put in a homenet router to make this work?   Which homenet router do I put it in?"   When I consider those questions, I don't know the answers to them.   I do know the answer for MPvD.   So that's why I proposed that approach.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 13 Aug 2017 12:52:45 +0200

Ted Lemon <[email-masked]> 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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 13 Aug 2017 08:27:26 -0400

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?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 13 Aug 2017 15:32:08 +0200

> vulnerable to scams would be very cool, but is out of scope for this

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 13 Aug 2017 10:48:47 -0400

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

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

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 13 Aug 2017 17:49:18 +0200

Ted Lemon <[email-masked]> writes:

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 13 Aug 2017 12:59:58 -0400

> ISP B's and going over the suboptimal path to get to the content (in

Not if the suboptimal path has substantially worse performance for the duration of the session.

> requiring hosts to support MPvD; and we're not supposed to require host

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?

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

> whatever we end up specifying).

That's fine with me!

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 13 Aug 2017 20:25:09 +0200

> Not if the suboptimal path has substantially worse performance for the

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.

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

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

>> whatever we end up specifying).

Cool :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 14 Aug 2017 22:21:08 +0200

> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 14 Aug 2017 22:24:48 +0200

> requiring hosts to support MPvD; and we're not supposed to require host

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

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Aug 2017 16:54:42 -0400

El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen <[email-masked]> va escriure:
>> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <[email-masked] <mailto:[email-masked]>> va escriure:

Indeed.  However, it is never a lose.

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

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

> PvD information and use the server anyway?

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Aug 2017 16:55:29 -0400

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 15 Aug 2017 13:37:59 +0200

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

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

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Aug 2017 09:21:39 -0400

> performance for the duration of the session? CDNs are used for other

Simple answer: don't wait five seconds.

> What are you basing this assessment on?

The prevalence of support for MPvD in existing hosts?

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

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 15 Aug 2017 21:38:47 +0200

Ted Lemon <[email-masked]> 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*.

> Can you describe for us what this implementation cost is that you want

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Aug 2017 16:28:52 -0400

> the DNS censorship issue; in my part of the world ISP DNS servers are

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.

> every router) is *not* going to incur a significant implementation and

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.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 16 Aug 2017 01:32:08 +0200

Ted Lemon <[email-masked]> writes:

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

> 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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Aug 2017 20:33:02 -0400

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

> it works on device X if I go into the kitchen".

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

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

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 16 Aug 2017 09:55:22 +0200

Moin!

> the DNS censorship issue; in my part of the world ISP DNS servers are
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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 16 Aug 2017 15:26:37 +0200

Ted Lemon <[email-masked]> writes:

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

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

> 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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 16 Aug 2017 15:33:55 +0200

> But don't blame all the ISPs to deliver broken service, without

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 09:37:17 -0400

El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen <[email-masked]> va escriure:
> Ted Lemon <[email-masked] <mailto:[email-masked]>> writes:
> 

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.

> if there's only one resolver it will be very obvious when it's not

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 09:40:11 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 09:50:17 -0400

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

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 16 Aug 2017 17:23:53 +0200

Ted Lemon <[email-masked]> writes:

> 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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 16 Aug 2017 17:24:08 +0200

Ted Lemon <[email-masked]> writes:

> 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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Aug 2017 15:50:36 -0400

Ted and Toke have many emails about DNS and servers and the like.
I think that it would be useful to take a few steps back to understand some
assumptions.  Many of these are tied up in layer 8 and layer 9 issues.

Toke wrote:  in my part of the world ISP DNS servers are
             broken *by design*

Ted meanwhile has written that that there are potential situations where
one provider may intentially misconfigure something so that a customer
will pick a more expensive way to get data.

In both cases we are trying to build into our protocols some kind of defense
against stupidity.   In Homenet, we are really trying to defend against
ISP stupidity, while trying to leverage intelligence from the ISP to guard
against end-user stupidity.

I don't pretend to capture their debate very well.

A lot of the DNS publish/public/private, etc. debate centers around tuscles
between clue-ful users (engineers) on this list who want to code something
sensible so that they can share their clue with the clueless, vs other
engineers who want to enable clue-ful ISPs to provide service to clueless
users.  Then the response from the first group is that this might force them
to do stupid things which they have fought against for ages.

I can not really characterise the debate very well, but this is what I think
I know:

1) ISPs that insist on controlling too much in the homenet will find
   themselves fighting against Googles, Apples (and Microsoft) who want it
   to work right.   We see this in the CAPPORT debates.
   By and large, "we" (the public) have "routed around" ISP stupidity, but
   the collatoral damage to the infrastructure has been immense. (e.g:
   NAPT44, SCTP, ...)

2) It's very hard to get people to vote with their wallet when it comes to
   poor ISP performance.  Performance usually means speed, but of course
   there is a whole lot of other variables.
   The 300Mb/s-marketing-speed fiber vs high-quality 50Mb/s IPv6, and my very
   technical friends pick the "faster" connection....
   Many times, it is because nobody has any actual information.  Such as,
   how often they are really getting 300Mb/s, or how often they are using
   IPv6 via a bad tunnel.

3) We've tried in HOMENET to automate things; and at the DNS space we are
   getting to limit of how much policy we can derive automatically.   There
   is SIGNIFICANT work that we can do to automate the implementation of the
   policy, if we can figure out what the policy is.

So I suggest that in order to make progress, we should split things up into
ways to implement a policy (assuming the policy is known a-priori), and ways
in which can we collect information about when the policy is failing so that
things can get fixed; perhaps by a local geek, perhaps by a clueful ISP
helpdesk, or eventually, perhaps by a smarter HNCP end-point.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Aug 2017 16:35:58 -0400

Hi,

I think I mostly agree with Michael, but I think I would emphasise a
couple other things:

On Wed, Aug 16, 2017 at 03:50:36PM -0400, Michael Richardson wrote:

> In Homenet, we are really trying to defend against

I think we're trying to make the homenet a proper part of the
Inter-net.  The Internet, of course, is a network of networks.  Part
of the idea there is that each network makes its own rules, which is
why we have to rely on voluntary interoperation.  Historically this
always depended on network administrators.  What I think we're trying
to do is to make network operation possible even when there is no
administrator.  Since there are lots of such basically
no-administration networks about, that doesn't seem crazy.

> helpdesk, or eventually, perhaps by a smarter HNCP end-point.

I think this is right, given the goal I think we're aiming for.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 16:48:23 -0400

I tend to agree with Andrew's re-interpretation, but I would add a caveat, which is that at least what I am trying to do is provide a DNS architecture the presence of which will enable devices to have the information and capabilities they need to operate successfully on a multi-homed residential network.   The fact that I've brought up a couple of use cases that relate to provider attacks is an artifact of where the conversation went, not a central theme in the work I'm trying to do.

My fear in reading Michael's message was that we'd go even further down the rathole of over-specialization.   That is not what I am trying to work on.   If it's what the working group wants to work on, I may be able to help, or it may be work for someone else.   This has been a pretty frustrating process for me, because I feel like I'm trying to do something sensible, I keep having to submit incremental versions of the document at times when my head is in a different document I'm working on to support the general goal, and I keep getting rotten tomatoes thrown at me because the document that gets produced isn't done and isn't consistent.   This is understandable, but it would be nice if instead of throwing rotten tomatoes people would help to do the work.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Aug 2017 23:24:59 +0200

> 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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Aug 2017 17:49:54 -0400

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" <[email-masked]> wrote:

> server on

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Aug 2017 10:26:51 -0400

> I think this is right, given the goal I think we're aiming for.

This suggests to me that the next step in HOMENET, which I think the naming
architecture could lead, is to provide for (automatic) collection of
statistics for diagnostics purposes.
i.e. Homenet OAM.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Aug 2017 10:31:25 -0400

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 17 Aug 2017 19:57:57 +0000

> architecture could lead, is to provide for (automatic) collection of statistics for
> diagnostics purposes.
> i.e. Homenet OAM.

Not as chair...
I disagree this has anything to do with the naming architecture.
I have long felt the best way to accomplish this would be to have a discoverable (DNS-SD) NetJSON (http://netjson.org/) "service" on all consumer routers, which would supply NetJSON types via http.
I agree supplying statistics info to the home network would be a good thing for homenet to tackle. 
I've been wanting to propose this for a while, but keep getting side-tracked.
Barbara

---

From: Gert Doering <[email-masked]>
Date: Thu, 17 Aug 2017 22:10:55 +0200

Hi,

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Aug 2017 21:33:32 -0400

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Aug 2017 11:40:57 +0200

> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2017 10:30:57 -0400

El 18 ag 2017, a les 5:40, Juliusz Chroboczek <[email-masked]> va escriure:
> 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.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Aug 2017 11:21:26 -0400

> I disagree this has anything to do with the naming architecture.

The reason I suggest that the naming architecture could lead this, is because
due to the multi-provider nature, we get specifically interesting statistics
From end-systems about how well they are communicating with their intended
targets.  Further, in order to deal with this kind of thing, there are host
changes desired, so doing OAM on those changes seems like not too much a stretch.

For instance, how many times did they pick a src/dst combination for a DNS
query, or a data transmission, for which there was a communication failure?

    > I have long felt the best way to accomplish this would be to have a
    > discoverable (DNS-SD) NetJSON (http://netjson.org/) "service" on all
    > consumer routers, which would supply NetJSON types via http.

    > I've been wanting to propose this for a while, but keep getting side-tracked.

You have described a mechanism to collect the statistics, and it seems like a
very good suggestion.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 Aug 2017 23:46:14 +0200

> 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