Danny, I entirely agree with what you say about the motivation for the work. But if I may be really picky, I think the required notification is not about link state per se, rather about source IP changes.
Suppose an application could find out about the different IP addresses available to it, and the costs & attributes of using each. Wouldn't that fulfill the use case in a very general manner? I can think of ways in which a different source address is appropriate even if link state was not lost. - network renumbering (even on a fixed network) - changes in cryptographically-generated IPv6 addresses - multi-homing changes, such as *adding* a WiFi interface without dropping a mobile interface. I note also that BSD allows IP addresses to be assigned to the loopback interface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.mo...@intel.com] Sent: Wednesday, August 12, 2015 7:44 AM To: Dave Dolson Cc: dmm@ietf.org Subject: RE: mobility and link state Hi Dave, Thanks for your comments. In general, I agree that it is preferable to hide data-link-related events from applications. At least, this use to be the case in the stationary world (as opposed to mobile). With the introduction of mobile platforms, the event of a temporary loss of connection is much more common (as a result of handoffs). Still, if the connection loss is temporary and lasts for a very short amount of time, and the source IP address is still valid after the connection is back, there is no real requirement for any specific action and that event could still be transparent to applications. But maintaining the source IP address (which is referred to in some drafts as: 'IP session continuity') come with a price: Maintaining tunnels, extra encapsulation header in each packet, non-optimal routes etc... We have acknowledged that some applications can easily recover from a source IP address change. This ability means that they do not benefit from the network's IP session continuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-Demand' concept in which applications have the ability to indicate to the NW their desire to receive different levels of IP session continuity services. The link-state change indication is another means to help applications that can recover from a change in source IP address (as a result of handoff). We believe that in the mobile world, application developers may benefit from being aware of the mobility behavior of the platform on which their applications are deployed. They do not have to be, but being aware can yield better performance (same goes for energy consumption - but this is out of the scope of DMM). To conclude, we are not requiring all future applications to be mobility-aware. We are offering means for applications to be mobility aware on their choice to enable them to behave in a more optimal manner in mobile platforms. /Danny From: Dave Dolson [mailto:ddol...@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: dmm@ietf.org<mailto:dmm@ietf.org> Subject: mobility and link state 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 --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
