Hi, This is turning to be an interesting discussion.
Regarding Dave's reply (before John reply): Actually, there are several motivations for indications from the link layer: 1. As Dave pointed out in his reply - to be aware of source IP address change - I agree that this is the most useful one 2. To be able to postpone sending packets when the link is down (assuming it is a temporary state) to prevent TCP time-outs (or other higher-level phenomena which could occur with UDP-based traffic) 3. To trigger a refresh of the source IP address in case of a potential triangle route as a result of a handoff (I tried to describe this in the scenario named: "Handoff - Sustained address - new LAN - better service available" in slides 15-16). I agree that there are different events that influence a change in the source IP address which could affect applications and I am still not sure what is the preferable level of exposure to them. Regarding John's comment: The work done so far in the exposure WT was more in the area of enabling applications to better specify their needs and have the network fulfill these needs. For example: App wants IP session continuity, so it requests a Sustained address and the network allocates one. The application is not exposed to the details of supporting IP session continuity and that is good. The link-state exposure topic is a little different in the sense that the applications request to be aware of events and are expected to handle them. This requires more mobility awareness from application developers. John's draft goes one step further: It assumes that application query the network about different paths and costs and makes intelligent decisions based on that information. I think each topic is useful, and although have some commonalities, should be separate work due to the level of awareness they require from application developers. /Danny From: Dave Dolson [mailto:[email protected]] Sent: Wednesday, August 12, 2015 21:31 To: John Kaippallimalil; Moses, Danny Cc: [email protected] Subject: RE: mobility and link state [- re: prefix cost] Yes, (by reading the abstract) that is roughly what I was thinking. I hope the group gets to a single idea that allows applications to choose the best IP addresses to bind to, without having to know anything about the access technology. Go no lower than the IP layer. Applications shouldn't have to know about 3G or LTE or WiFi or 100baseT or VPN connections... From: John Kaippallimalil [mailto:[email protected]] Sent: Wednesday, August 12, 2015 2:18 PM To: Dave Dolson; Moses, Danny Cc: [email protected]<mailto:[email protected]> Subject: RE: mobility and link state [- re: prefix cost] Dave, With reference to "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?" Pete and I have a draft - http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addresses exactly what you state above on the network (between router and host). Is this close to what you are thinking about? PS: I did receive a number of comments during the IETF presentation and will be updating soon. One of the comments was regarding how the host (and application) can use this information. Best Regards, John From: dmm [mailto:[email protected]] On Behalf Of Dave Dolson Sent: Wednesday, August 12, 2015 7:53 AM To: Moses, Danny Cc: [email protected]<mailto:[email protected]> Subject: Re: [DMM] mobility and link state 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:[email protected]] Sent: Wednesday, August 12, 2015 7:44 AM To: Dave Dolson Cc: [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: [email protected]<mailto:[email protected]> 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. --------------------------------------------------------------------- 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 [email protected] https://www.ietf.org/mailman/listinfo/dmm
