Subject: [DMM] mobility and link state

From: Dave Dolson <[email-masked]>
Date: Mon, 20 Jul 2015 23:51:50 +0000

Danny,
Although I'm new to this working group, today I watched you present at IETF on the subject of applications monitoring link state.
You asked for feedback on the mailing list... Maybe some of these ideas are useful:

Thinking as an application author,

-          I think some kind of signal about network loss is useful, rather than applications using arbitrary timeouts on transaction times. Example: when should a browser or database client give up on a request? The timeout approach is unsatisfactory for transactions that take a long time to run.

-          Having said that, the application should not have to know about links or layer2 health.

-          Links should be able to go up and down, without dropping a TCP connection, for example. I feel there is a strong tradition of this behavior. IP addresses should be able to move between interfaces (e.g., from a physical interface to a tunnel interface) without interruption of the socket.

-          but one thing that warrants an exception is when the address bound by the socket is no longer available on the host. I believe current behavior a socket will stay alive even when the IP address is no longer available on the host, presumably in the hope that the IP address will be assigned again.

-           The socket should only fail if the transaction is not going to finish. In mobility context this might mean that the loss of the IP address is likely permanent (what is "permanent"? --> need heuristics).

-          Typical applications will connect with "any" for the source address to bind to. When a host has multiple IP addresses (multi-homed), there is a complicated set of rules for choosing one (RFC 6724). Your thoughts on choosing best routes may fit in this framework. (Is RFC 5014 relevant here?)

So my proposal, which I think can be backwards compatible:

-          Add an ioctl or getsockopt so that the application can ask, "would there be a better choice of local address", giving the application an opportunity to start another socket at the best opportunity (after the current transaction).

-          Add a socket option for the idea of "create socket error if local IP has been lost for X seconds". I propose the timeout, allowing an IP address to be removed from one interface and added to another without socket error. This is better than an application timeout.

Consider the case of a database client using a persistent database connection for queries.
To handle the soft hand-over case a smart client would keep checking if the socket is optimal. If not, finish the current transaction on the existing socket and open a new socket for new transactions. The new socket presumably uses the newer and better local IP address.

-Dave