Subject: [mif] Server selection document is "band-aid" not solution

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Nov 2011 10:11:30 +0800

I sorry for the late comment but it has taken me a while to be able to 
put my finger on what I feel is wrong with the document (and the 
discussion in the working group)

If a node has multiple interfaces and the interfaces have different 
resolution contexts then the basic question is
"How can the services on the node tell what resolution context an 
application wants to use ?"

Right now the "server-selection" document
The fundamental problem we have is that OS's have a built in assumptions 
that
a) there is only one resolution context i.e. only single /etc/resolv.conf

b) There is no way to label a process that it wants to be a part of 
certain resolution context or tell the resolution which context to use.

c) Results of resolution do not indicate which context was used.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 15:41:00 +1300

> c) Results of resolution do not indicate which context was used.

These are all symptoms of a much deeper problem that we have in the
modern Internet: the notion of scope that we have, for both names
and addresses, is broken, and inconsistent with the real world.
I've been trying to get people interested in this for a while,
e.g. http://tools.ietf.org/html/draft-carpenter-referral-ps

There's actually more explicit discussion of scope in an even
older draft, most of which is OBE:
http://tools.ietf.org/html/draft-carpenter-grobj-reqts-00#section-2

However, I don't believe MIF can be expected to solve this problem,
and therefore the server selection draft seems to be the best
that MIF can do.

    Brian

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 02:47:45 +0000

Hi,

Thank you for your comment, but I don't really see what you are proposing.

The current state document shows how some OSes provide means for applications to specify "context" (e.g. by apps explicitly specifying what network interface they want to use, which impacts to all stack behavior: DNS, address selection, routing). The system where *all* applications must specifically tell to OS what network interface to use is considered not to be very nice for most application developers..

The DNS server selection document indeed assumes applications do not provide preference on what "context" they want to use - because generally applications just don't know that information, and we want to avoid bothering users with network selection UI dialogs.

Perhaps the MIF API document could cover your concern? I.e. introduce an API for applications to specify "context" in a manner that it affects also DNS resolution procedure (or maybe it is there, I need to read it:) This explicit API could/would then override the DNS server selection information received from the network - for the application that knows better.

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Olafur Gudmundsson
> Sent: 17. marraskuuta 2011 10:12
> To: [email-masked]
> Subject: [mif] Server selection document is "band-aid" not solution
> 
> 
> I sorry for the late comment but it has taken me a while to be able to put my
> finger on what I feel is wrong with the document (and the discussion in the
> working group)
> 
> If a node has multiple interfaces and the interfaces have different resolution
> contexts then the basic question is "How can the services on the node tell
> what resolution context an application wants to use ?"
> 
> Right now the "server-selection" document The fundamental problem we
> have is that OS's have a built in assumptions that
> b) There is no way to label a process that it wants to be a part of certain
> resolution context or tell the resolution which context to use.
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 16:05:04 +1300

Teemu,

I don't see how we could define a helpful API until the generic problem
of scope is solved (see my previous message). We have no general way
for an application to know or describe the scope that applies to itself and
the peer(s) it wants to talk to.

Regards
   Brian

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 03:48:16 +0000

Brian,

I was thinking about class of applications that might be configured (by user or by administrator or e.g. by ISP using over-the-air provisioning technologies, etc) to work only with specific contexts. The API could make it easier to implement those apps.

But I agree with your email about bigger problem and difficulties on finding generic solution for that.

Best regards,

        Teemu

> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 17. marraskuuta 2011 11:05
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mif] Server selection document is "band-aid" not solution
>
> Teemu,
>
> I don't see how we could define a helpful API until the generic problem of
> scope is solved (see my previous message). We have no general way for an
> application to know or describe the scope that applies to itself and the
> peer(s) it wants to talk to.
>
> Regards
>    Brian
>
> > The current state document shows how some OSes provide means for
> applications to specify "context" (e.g. by apps explicitly specifying what
> network interface they want to use, which impacts to all stack behavior: DNS,
> address selection, routing). The system where *all* applications must
> specifically tell to OS what network interface to use is considered not to be
> very nice for most application developers..
> >
> > The DNS server selection document indeed assumes applications do not
> provide preference on what "context" they want to use - because generally
> applications just don't know that information, and we want to avoid
> bothering users with network selection UI dialogs.
> >
> > Perhaps the MIF API document could cover your concern? I.e. introduce an
> API for applications to specify "context" in a manner that it affects also DNS
> resolution procedure (or maybe it is there, I need to read it:) This explicit API
> could/would then override the DNS server selection information received
> from the network - for the application that knows better.
> >
> > Best regards,
> >
> >     Teemu
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >> ext Olafur Gudmundsson
> >> I sorry for the late comment but it has taken me a while to be able
> >> to put my finger on what I feel is wrong with the document (and the
> >> resolution contexts then the basic question is "How can the services
> >> on the node tell what resolution context an application wants to use ?"
> >>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 04:52:13 +0000

> and therefore the server selection draft seems to be the best

On the contrary, this is _exactly_ the problem MIF should be solving.   And I agree 100% that server selection is just a bandaid.   Really it's not even that: it's a hint that some DNS subdomains ought to be resolved by specific DNS servers in a specific provisioning domain, but it doesn't even address the larger problem.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 04:54:18 +0000

> the peer(s) it wants to talk to.

It seems to me that applications "knowing" what scope they want to talk to is a very isolated special case.   E.g., perhaps your set-top box knows that it needs to go through your cable ISP's provisioning domain to get streaming video.   But generally speaking, your application wants to connect through whatever provisioning domain works best, which is something no provisioning domain can claim to know; it is something only the host can determine.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 00:26:28 -0500

On Nov 16, 2011, at 9:11 PM, Olafur Gudmundsson wrote:

> 
> I sorry for the late comment but it has taken me a while to be able to put my finger on what I feel is wrong with the document (and the discussion in the working group)
> 
> If a node has multiple interfaces and the interfaces have different resolution contexts then the basic question is
> "How can the services on the node tell what resolution context an application wants to use ?"
> 
> The fundamental problem we have is that OS's have a built in assumptions that

It's not just that.  A fundamental design choice of DNS is that there is only one resolution context.  Yes, it's not unusual for that design choice to be violated.  But that still doesn't make it right for MIF to violate it.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 05:34:58 +0000

> It's not just that.  A fundamental design choice of DNS is that there is only one resolution context.  Yes, it's not unusual for that design choice to be violated.  But that still doesn't make it r…

Do you mean only one namespace?  It is not at all a fundamental assumption of the DNS that there is only one resolution context.   That is an implementation artifact that actually must be fixed if we are going to come up with a good solution to the MIF problem statement.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 00:40:49 -0500

On Nov 17, 2011, at 12:34 AM, Ted Lemon wrote:

> Do you mean only one namespace?  It is not at all a fundamental assumption of the DNS that there is only one resolution context.   

Either I disagree, or we're talking about different things.  But DNS cacheing assumes that the correct set of answers to a particular DNS query are the same independent of where the query came from.  This isn't an implementation artifact, it's how DNS was designed to work.  

Keith

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 06:02:29 +0000

Latest revision says:
--
   Private namespaces MUST be globally unique in order to keep DNS
   unambiguous and henceforth avoiding caching related issues and
   destination selection problems (see Section 2.3).  Exceptions to this
   rule are domains utilized for local name resolution (such as .local).

   Private namespaces MUST only consist of subdomains of domains for
   which the relevant operator provides authoritative name service.
   Thus, subdomains of example.com are permitted in the private
   namespace served by an operator's DNS servers only if the same
   operator provides an SOA record for example.com.
--
Doesn't that make DNS caches happy?

        Teemu

> Keith Moore
> Sent: 17. marraskuuta 2011 13:41
> To: Ted Lemon
> Cc: [email-masked]
> >> It's not just that.  A fundamental design choice of DNS is that there is only
> one resolution context.  Yes, it's not unusual for that design choice to be
> violated.  But that still doesn't make it right for MIF to violate it.
> >
> > Do you mean only one namespace?  It is not at all a fundamental
> assumption of the DNS that there is only one resolution context.
>
> Either I disagree, or we're talking about different things.  But DNS cacheing
> assumes that the correct set of answers to a particular DNS query are the
> same independent of where the query came from.  This isn't an
> implementation artifact, it's how DNS was designed to work.
>
> Keith
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 06:19:49 +0000

> Either I disagree, or we're talking about different things.  But DNS cacheing assumes that the correct set of answers to a particular DNS query are the same independent of where the query came from…

Right, so that's the uniform namespace assumption.   But if you have two routers querying two different sets of servers, this is a non-issue.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Nov 2011 01:01:28 -0500

On Thu, Nov 17, 2011 at 02:47:45AM +0000, [email-masked] wrote:

> provide preference on what "context" they want to use - because
> generally applications just don't know that information, and we want
> to avoid bothering users with network selection UI dialogs.

No, the reason applications don't have that interface is because we
told them that the DNS is a unified name space.  That's its design.
(This is part of Olafur's point, if I read him correctly.)

As a matter of fact, because of what people have done with the DNS, it
is _not_ a unified name space, and you will indeed get different
answers on different interfaces.  Moreover, vendors (who perhaps ought
to have known better) have attempted to fix that by adding curious
different ways of not experiencing too much pain whenever this
situation arises.

The reason that we need the server selection document, therefore, is
that we want people to do this hackery in a way that causes the least
harm.  We shouldn't mistake this attempt to do the least bad thing as
itself good.

You're quite right, however, that we don't want to bother users with a
server selection UI for these cases, but I disagree that it's because
it would be "bothering" them.  I'd be happy to bother them if I
thought there to be the remotest hope they could answer the question
we'd have to ask.  They just want to be able to go where they want to
go, and if the idea of the right network context were the sort of
thing that was coherent to most users, we probably wouldn't need to be
doing these sorts of work-arounds for private DNS names in the first
place.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 08:34:14 -0500

> Right, so that's the uniform namespace assumption.   But if you have two routers querying two different sets of servers, this is a non-issue.

Actually, that's not even true.  And to the extent it is true, that is an implementation artifact. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 09:30:24 -0500

On Nov 17, 2011, at 1:01 AM, Andrew Sullivan wrote:

> answers on different interfaces.

In other words, people have used DNS in a way that is contrary to its design, and in the past it has happened to (often) work only because hosts tended to have only one active interface to the network that provided DNS at any given time.

>  Moreover, vendors (who perhaps ought
> harm.  

If we want that to happen then the server selection document should make it explicit that the results of any DNS query via any network interface MAY be used to establish a connection on any network interface.

Or maybe there needs to be some way to distinguish name servers serving private namespaces from those serving public name spaces, so that the host can tell the difference.   Ideally that should be communicated by the private name servers themselves in every DNS response that involves a private name.  Then the host would know that that specific response was interface-specific.

Keith

---

From: <[email-masked]>
Date: Thu, 17 Nov 2011 17:59:35 +0000

> If we want that to happen then the server selection document should make it
> explicit that the results of any DNS query via any network interface MAY be
> used to establish a connection on any network interface.

Source and destination address selection is a separate process and described in different documents.

One could do even happy eyeballs after having the result back from DNS and try'em'all in parallel.

        Teemu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 20:37:50 +0000

> Actually, that's not even true.  And to the extent it is true, that is an implementation artifact. 

Wow, I don't know where my brain was just then.   I meant "resolvers," not "routers."

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 15:39:22 -0500

> Wow, I don't know where my brain was just then.   I meant "resolvers," not "routers."

I just assumed you meant separate data paths, including all of resolvers, routers, network links, etc.

Seriously, dual-facing servers are the implementation artifacts.  It's an accident that they work at all.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 12:25:14 +1300

> One could do even happy eyeballs after having the result back from DNS and try'em'all in parallel.

IMHO Keith and Teemu are both correct, and all these three points should be made
clear in paragraph 4 of the Introduction to draft-ietf-mif-dns-server-selection.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 14:18:20 +1300

Ted,

> It seems to me that applications "knowing" what scope they want to talk to is a very isolated special case.   E.g., perhaps your set-top box knows that it needs to go through your cable ISP's provi…

Ultimately, only the hosts involved in a particular transaction can discover
what works best for them, which is why SCTP, MPTCP and SHIM6/REAP were
invented, as well as happy-eyeballs.

However these (and any other) host mechanisms need an initial set of address
pairs to try out and, in many cases, an order of preference in which to
try them. In some cases (but not all) DNS may be source of a set of
destination addresses, but it's only the routing system that can provide
a priori information about which address *pairs* are worth trying.

> On the contrary, this is _exactly_ the problem MIF should be solving.   And I agree 100% that server selection is just a bandaid.   Really it's not even that: it's a hint that some DNS subdomains o…

Well it's above my pay grade to make the calls about what is in scope
for this WG, but it seems to me that it's a quite general architectural
problem and MIF has a more tactical remit.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 02:13:18 +0000

> Seriously, dual-facing servers are the implementation artifacts.  It's an accident that they work at all.

Sorry, Keith, I'm having trouble parsing this.   If you have a point to make, it would help if it involved statements about things that work or don't work, and explanations as to why, not characterizations of the origins of various pieces of software and your opinion of their ontological status.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 02:17:09 +0000

> a priori information about which address *pairs* are worth trying.

Can you provide an example of a case where the routing system has the capacity to do this in a MIF setting where you have two interfaces connected to separate administrative domains?   I agree at least in principle that you may be able to come up with some special case where you could decide on the basis of some such information which pair to try first.   However, I am pretty sure that a general solution will not be able to rely on whatever information source you rely on in whatever special case you cite.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Nov 2011 22:22:13 -0500

> invented, as well as happy-eyeballs.

Well, ultimately, only the applications involved in a particular transaction can discover these things, because what's good for one application isn't necessarily good for another.  Which is why trying to make e.g. happy eyeballs into a general-purpose mechanism is probably a poor idea.

> a priori information about which address *pairs* are worth trying.

That is certainly how it should be.  Anything based on heuristics, in the absence of routing information provided by the routing system, is just a hack.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 16:26:03 +1300

> Can you provide an example of a case where the routing system has the capacity to do this in a MIF setting where you have two interfaces connected to separate administrative domains?   I agree at l…

Today? Probably not. But that doesn't mean it shouldn't be a
goal. Things like knowing which egresses are subject to which
ingress filters, for example, could be known to the border routers.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Nov 2011 05:14:31 +0000

> ingress filters, for example, could be known to the border routers.

I am skeptical that my hotel will get this right.   And they _do_ typically have egress filters.   So it seems like a shaky foundation upon which to base a general solution.