Subject: Re: [DMM] mobility and link state

From: "Moses, Danny" <[email-masked]>
Date: Wed, 12 Aug 2015 11:44:19 +0000

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-masked]]
Sent: Tuesday, July 21, 2015 02:52
To: Moses, Danny
Cc: [email-masked]
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.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 12:53:13 +0000

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-masked]]
Sent: Wednesday, August 12, 2015 7:44 AM
To: Dave Dolson
Cc: [email-masked]
Subject: RE: mobility and link state

Hi Dave,

/Danny

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, July 21, 2015 02:52
To: Moses, Danny
Cc: [email-masked]<mailto:[email-masked]>
Subject: mobility and link state

Danny,

-Dave

---

From: John Kaippallimalil <[email-masked]>
Date: Wed, 12 Aug 2015 18:17:57 +0000

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-masked]] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: [email-masked]
Subject: Re: [DMM] mobility and link state

Danny,

-Dave

Hi Dave,

/Danny

Danny,

-Dave

---

From: Dave Dolson <[email-masked]>
Date: Wed, 12 Aug 2015 18:30:50 +0000

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-masked]]
Sent: Wednesday, August 12, 2015 2:18 PM
To: Dave Dolson; Moses, Danny
Cc: [email-masked]
Subject: RE: mobility and link state [- re: prefix cost]

Dave,

Best Regards,
John

Danny,

-Dave

Hi Dave,

/Danny

Danny,

-Dave

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 13 Aug 2015 06:42:08 +0000

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-masked]]
Sent: Wednesday, August 12, 2015 21:31
To: John Kaippallimalil; Moses, Danny
Cc: [email-masked]
Subject: RE: mobility and link state [- re: prefix cost]

Dave,

Best Regards,
John

Danny,

-Dave

Hi Dave,

/Danny

Danny,

-Dave

---

From: John Kaippallimalil <[email-masked]>
Date: Thu, 13 Aug 2015 14:35:57 +0000

Hi Danny,
Some thoughts and clarifications :

*         "As Dave pointed out in his reply - to be aware of source IP address change - I agree that this is the most useful one"
We should keep in mind that there is no 1:1 relationship between IP source address change and link change.
For example, a host may move from one eNB/SGW to another and still have the same IP address. Conversely, I suppose the current link/IP address may be available, and yet a new IP address maybe preferable.

*         "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"
The draft on prefix-cost assumes that the application can be informed by the network stack/OS about a more preferable IP address. Applications that do not need this operate as they do today. The subset of applications that want application level continuity insert an new socket option, and poll the network stack/OS for this information. It would be application behavior and other policies that determine if a new IP address is added (e.g., MPTCP), or the current one is replaced (e.g., cost is too high).
Please note that this is not the main aim of the prefix-cost draft - it describes how a host can learn the network "costs" per IP prefix.  However, the draft (or a companion draft) should point to a feasible way for the host to use this information. Plan to start documenting this in the next revision of the draft and suggestions/input is welcome.

BR,
John

From: Moses, Danny [mailto:[email-masked]]
Sent: Thursday, August 13, 2015 1:42 AM
To: Dave Dolson; John Kaippallimalil
Cc: [email-masked]
Subject: RE: mobility and link state [- re: prefix cost]

Hi,

/Danny

Dave,

Best Regards,
John

Danny,

-Dave

Hi Dave,

/Danny

Danny,

-Dave