Rewrite Interface Types to be useful and implementable

[britram]

We should be a bit more specific about how an application is supposed to interact with path selection properties. Do we want to bind this to a world in which the system specifies a set of interface type labels and the application has to choose, or is there some other approach here?

[tfpauly]

So, one approach is to indeed have enumerations of path types and services that are allowed. To give the example of how we do this:

• Require/Prohibit/etc "interface name" like "en0". This sucks, but is on occasion necessary if you need to be really specific as an application.

• Require/Prohibit/etc "interface type", which is "Wi-Fi", "Wired Ethernet", "Cellular", "Loopback"; with subtypes for "Peer-to-Peer Wi-Fi", etc.

• Require/Prohibit/etc "service", "PvD" or what we call a "network agent". This can be a class of a network service like "VPN", "Proxy", etc, or a specific instance of a VPN, etc.

That last category allows a fairly extensible set of options. I think in general, this area should take lessons from the PvD work. See: https://tools.ietf.org/html/draft-kline-mif-mpvd-api-reqs-00

[britram]

do we need to assign someone to write text for this for the -00 milestone, or can we come back to this after London?

[philsbln]

I am fine with moving this to post-London

[gorryfair]

I think we need to address what I think is a basic issue in the API draft. The current text seems to suggest the App signals specific characteristics of the App across the API. I have problems with this - the experience from RSVP, etc - is that Apps seldom understand how to express themselves regarding their own behaviour. Instead, I would advocate that we explicitly focus on what they want from the network path:

Examples I suggest are helpful include: an abstract treatment based on a PHB; a minimum PMTU; a preference for lower latency rather than throughput; a need for no cost... etc. Examples I would argue against: A need for a specific transmission rate; understanding of the size of a transfer at the time the connection is made; ... etc.

[tfpauly]

+1 for specifying requirements of paths and protocols, rather than properties of an application. Any time we've attempted to implement the items you mention as the "argue against", they've been dead ends that have either been misused or deprecated.

[philsbln]

Lets look how many use cases for this stay when you add support for requesting explicit pvds

[britram]

@tfpauly: As discussed during the 16 May interim, Types should definitely be system-specific. Specific interface names and specific PvDs are definitely useful, but are probably also too system-specific to be able to generalize.

[britram]

181 closed this