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

[Keith Moore <[e-mail]>]

On Nov 17, 2011, at 8:18 PM, Brian E Carpenter wrote:

> Ted,
> 
> On 2011-11-17 17:54, Ted Lemon wrote:
>> On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" <[e-mail]> wrote:
>>> 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.
>> 
>> 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.
> 
> 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.

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.

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

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