Ted, On 2011-11-17 17:54, Ted Lemon wrote: > On Nov 17, 2011, at 11:05 AM, "Brian E Carpenter" > <[email protected]> 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. 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 2011-11-17 17:52, Ted Lemon wrote: > On Nov 17, 2011, at 10:41 AM, "Brian E Carpenter" > <[email protected]> wrote: >> > 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. > > 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. 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 _______________________________________________ mif mailing list [email protected] https://www.ietf.org/mailman/listinfo/mif
