From nobody Wed Aug 12 04:44:29 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE25C1A90F1 for ; Wed, 12 Aug 2015 04:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4szX7CZhTnhX for ; Wed, 12 Aug 2015 04:44:23 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 773541A9045 for ; Wed, 12 Aug 2015 04:44:23 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 12 Aug 2015 04:44:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,660,1432623600"; d="scan'208,217";a="767164601" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by fmsmga001.fm.intel.com with ESMTP; 12 Aug 2015 04:44:22 -0700 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 12 Aug 2015 12:44:21 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.53]) by hasmsx108.ger.corp.intel.com ([169.254.9.48]) with mapi id 14.03.0224.002; Wed, 12 Aug 2015 14:44:19 +0300 From: "Moses, Danny" To: Dave Dolson Thread-Topic: mobility and link state Thread-Index: AdDCwBdzhVkC8FdiRYipkVsxU2qoGgSMTOgQ Date: Wed, 12 Aug 2015 11:44:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.11] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813495E9EFHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 11:44:28 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813495E9EFHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms. /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813495E9EFHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Thanks for your commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering 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 Dol= son [mailto:ddolson@sandvine.com]
Sent: Tuesday, July 21, 2015 02:52
To: Moses, Danny
Cc: 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 lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signa= l about network loss is useful, rather than applications using arbitrary ti= meouts on transaction times. Example: when should a browser or database cli= ent give up on a request? The timeout approach is unsatisfactory for transactions that take a long time to run.<= o:p>

-     &= nbsp;    Having said that, the appl= ication should not have to know about links or layer2 health.

-     &= nbsp;    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 sock= et.

-     &= nbsp;    but one thing that warrant= s an exception is when the address bound by the socket is no longer availab= le on the host. I believe current behavior a socket will stay alive even wh= en the IP address is no longer available on the host, presumably in the hope that the IP address will be assigned a= gain.

 

-     &= nbsp;     The socket should on= ly 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 &#= 8220;permanent”? --> need heuristics).

-     &= nbsp;    Typical applications will = connect with “any” for the source address to bind to. When a ho= st has multiple IP addresses (multi-homed), there is a complicated set of r= ules for choosing one (RFC 6724). Your thoughts on choosing best routes may fit in this framework. (Is RFC 5014 relevant h= ere?)

 

So my proposal, which I think can be backwards compa= tible:

-     &= nbsp;    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 anothe= r socket at the best opportunity (after the current transaction).

-     &= nbsp;    Add a socket option for th= e idea of “create socket error if local IP has been lost for X second= s”. 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 persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_F0CF5715D3D1884BAC731EA1103AC2813495E9EFHASMSX106gercor_-- From nobody Wed Aug 12 05:53:23 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8661B2D67 for ; Wed, 12 Aug 2015 05:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61IoEutkSbwW for ; Wed, 12 Aug 2015 05:53:16 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6E1B2D63 for ; Wed, 12 Aug 2015 05:53:15 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.03.0195.001; Wed, 12 Aug 2015 08:53:13 -0400 From: Dave Dolson To: "Moses, Danny" Thread-Topic: mobility and link state Thread-Index: AdDCwBdzhVkC8FdiRYipkVsxU2qoGgSMTOgQAALZJ7A= Date: Wed, 12 Aug 2015 12:53:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830CB779Bwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 12:53:22 -0000 --_000_E8355113905631478EFF04F5AA706E9830CB779Bwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 abou= t link state per se, rather about source IP changes. Suppose an application could find out about the different IP addresses avai= lable to it, and the costs & attributes of using each. Wouldn't that fulfil= l 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 int= erface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.moses@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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms= . /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_E8355113905631478EFF04F5AA706E9830CB779Bwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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, r= ather about source IP changes.

 

Suppose an application= could find out about the different IP addresses available to it, and the c= osts & attributes of using each. Wouldn’t that fulfill the use ca= se 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 cryptogra= phically-generated IPv6 addresses

- multi-homing changes= , such as *adding* a WiFi interface without dropping a mobile interf= ace.

 

I note also that BSD a= llows IP addresses to be assigned to the loopback interface, the state of w= hich never changes.

 

-Dave

 

 

 

From: Moses, D= anny [mailto:danny.moses@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 commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering means for applications to be mobility aware on their choice to enable= them to behave in a more optimal manner in mobile platforms.

 

/Danny

 

 

Danny,

Although I’m new to this working group, today = I watched you present at IETF on the subject of applications monitoring lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signal about network loss is u= seful, rather than applications using arbitrary timeouts on transaction tim= es. 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.

-     &= nbsp;    Having said that, the application should not have t= o know about links or layer2 health.

-     &= nbsp;    Links should be able to go up and down, without dro= pping 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.

-     &= nbsp;    but one thing that warrants an exception is when th= e 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 l= onger available on the host, presumably in the hope that the IP address will be assigned again.

 

-     &= nbsp;     The socket should only fail if the transactio= n 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).

-     &= nbsp;    Typical applications will connect with “any&#= 8221; for the source address to bind to. When a host has multiple IP addres= ses (multi-homed), there is a complicated set of rules for choosing one (RF= C 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 compa= tible:

-     &= nbsp;    Add an ioctl or getsockopt so that the application = can ask, “would there be a better choice of local address”, giv= ing the application an opportunity to start another socket at the best oppo= rtunity (after the current transaction).

-     &= nbsp;    Add a socket option for the idea of “create s= ocket error if local IP has been lost for X seconds”. I propose the t= imeout, allowing an IP address to be removed from one interface and added t= o another without socket error. This is better than an application timeout.

 

Consider the case of a database client using a persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_E8355113905631478EFF04F5AA706E9830CB779Bwtlexchp1sandvi_-- From nobody Wed Aug 12 11:18:26 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCD1AC3D5 for ; Wed, 12 Aug 2015 11:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79dhw-Bt8Hv1 for ; Wed, 12 Aug 2015 11:18:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5EA1AC3AD for ; Wed, 12 Aug 2015 11:18:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZU57126; Wed, 12 Aug 2015 18:18:11 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 12 Aug 2015 19:18:10 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Wed, 12 Aug 2015 11:17:57 -0700 From: John Kaippallimalil To: Dave Dolson , "Moses, Danny" Thread-Topic: mobility and link state [- re: prefix cost] Thread-Index: AQHQ1Ss2zAYbSZ8GbEmydQYfMGN3QA== Date: Wed, 12 Aug 2015 18:17:57 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB032ED@dfweml703-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.71] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB032EDdfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state [- re: prefix cost] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:18:24 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB032EDdfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, With reference to "Suppose an application could find out about the differen= t IP addresses available to it, and the costs & attributes of using each. W= ouldn'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 (bet= ween 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 wil= l be updating soon. One of the comments was regarding how the host (and app= lication) can use this information. Best Regards, John From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, August 12, 2015 7:53 AM To: Moses, Danny Cc: dmm@ietf.org 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 abou= t link state per se, rather about source IP changes. Suppose an application could find out about the different IP addresses avai= lable to it, and the costs & attributes of using each. Wouldn't that fulfil= l 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 int= erface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.moses@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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms= . /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_6561EABF52675C45BCDACA1B4D7AA1171DB032EDdfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

With reference to R= 20;Suppose an application could find o= ut about the different IP addresses available to it, and the costs & at= tributes of using each. Wouldn’t that fulfill the use case in a very general manner?= 221;

 

Pete and I have a draf= t - http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addre= sses 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 nu= mber of comments during the IETF presentation and will be updating soon. On= e of the comments was regarding how the host (and application) can use this= information.

 

Best Regards,

John=

 

 

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: dmm@ietf.org
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, r= ather about source IP changes.

 

Suppose an application= could find out about the different IP addresses available to it, and the c= osts & attributes of using each. Wouldn’t that fulfill the use ca= se 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 cryptogra= phically-generated IPv6 addresses

- multi-homing changes= , such as *adding* a WiFi interface without dropping a mobile interf= ace.

 

I note also that BSD a= llows IP addresses to be assigned to the loopback interface, the state of w= hich never changes.

 

-Dave

 

 

 

From: Moses, D= anny [mailto:danny.moses@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 commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering means for applications to be mobility aware on their choice to enable= them to behave in a more optimal manner in mobile platforms.

 

/Danny

 

 

Danny,

Although I’m new to this working group, today = I watched you present at IETF on the subject of applications monitoring lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signal about network loss is u= seful, rather than applications using arbitrary timeouts on transaction tim= es. 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.

-     &= nbsp;    Having said that, the application should not have t= o know about links or layer2 health.

-     &= nbsp;    Links should be able to go up and down, without dro= pping 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.

-     &= nbsp;    but one thing that warrants an exception is when th= e 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 l= onger available on the host, presumably in the hope that the IP address will be assigned again.

 

-     &= nbsp;     The socket should only fail if the transactio= n 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).

-     &= nbsp;    Typical applications will connect with “any&#= 8221; for the source address to bind to. When a host has multiple IP addres= ses (multi-homed), there is a complicated set of rules for choosing one (RF= C 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 compa= tible:

-     &= nbsp;    Add an ioctl or getsockopt so that the application = can ask, “would there be a better choice of local address”, giv= ing the application an opportunity to start another socket at the best oppo= rtunity (after the current transaction).

-     &= nbsp;    Add a socket option for the idea of “create s= ocket error if local IP has been lost for X seconds”. I propose the t= imeout, allowing an IP address to be removed from one interface and added t= o another without socket error. This is better than an application timeout.

 

Consider the case of a database client using a persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB032EDdfweml703chm_-- From nobody Wed Aug 12 11:31:02 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB481A1B91 for ; Wed, 12 Aug 2015 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQTVRHTYgQhR for ; Wed, 12 Aug 2015 11:30:55 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2331A1A56 for ; Wed, 12 Aug 2015 11:30:55 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 12 Aug 2015 14:30:52 -0400 From: Dave Dolson To: John Kaippallimalil , "Moses, Danny" Thread-Topic: mobility and link state [- re: prefix cost] Thread-Index: AQHQ1Ss7wy3G7i2VzkyjWZzrhpEWg54IrhFw Date: Wed, 12 Aug 2015 18:30:50 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB032ED@dfweml703-chm> In-Reply-To: <6561EABF52675C45BCDACA1B4D7AA1171DB032ED@dfweml703-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830CB925Dwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state [- re: prefix cost] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:31:01 -0000 --_000_E8355113905631478EFF04F5AA706E9830CB925Dwtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 t= he 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:John.Kaippallimalil@huawei.com] Sent: Wednesday, August 12, 2015 2:18 PM To: Dave Dolson; Moses, Danny Cc: dmm@ietf.org Subject: RE: mobility and link state [- re: prefix cost] Dave, With reference to "Suppose an application could find out about the differen= t IP addresses available to it, and the costs & attributes of using each. W= ouldn'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 (bet= ween 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 wil= l be updating soon. One of the comments was regarding how the host (and app= lication) can use this information. Best Regards, John From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, August 12, 2015 7:53 AM To: Moses, Danny Cc: dmm@ietf.org 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 abou= t link state per se, rather about source IP changes. Suppose an application could find out about the different IP addresses avai= lable to it, and the costs & attributes of using each. Wouldn't that fulfil= l 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 int= erface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.moses@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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms= . /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_E8355113905631478EFF04F5AA706E9830CB925Dwtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, (by reading the a= bstract) 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 t= o bind to, without having to know anything about the access technology.

Go no lower than the I= P layer. Applications shouldn’t have to know about 3G or LTE or WiFi = or 100baseT or VPN connections…

 

 

 

From: John Kai= ppallimalil [mailto:John.Kaippallimalil@huawei.com]
Sent: Wednesday, August 12, 2015 2:18 PM
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Dave,

With reference to R= 20;Suppose an application could find o= ut about the different IP addresses available to it, and the costs & at= tributes of using each. Wouldn’t that fulfill the use case in a very general manner?= 221;

 

Pete and I have a draf= t - http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addre= sses 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 nu= mber of comments during the IETF presentation and will be updating soon. On= e of the comments was regarding how the host (and application) can use this= information.

 

Best Regards,

John=

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: dmm@ietf.org
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, r= ather about source IP changes.

 

Suppose an application= could find out about the different IP addresses available to it, and the c= osts & attributes of using each. Wouldn’t that fulfill the use ca= se 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 cryptogra= phically-generated IPv6 addresses

- multi-homing changes= , such as *adding* a WiFi interface without dropping a mobile interf= ace.

 

I note also that BSD a= llows IP addresses to be assigned to the loopback interface, the state of w= hich never changes.

 

-Dave

 

 

 

From: Moses, D= anny [mailto:danny.moses@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 commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering means for applications to be mobility aware on their choice to enable= them to behave in a more optimal manner in mobile platforms.

 

/Danny

 

 

Danny,

Although I’m new to this working group, today = I watched you present at IETF on the subject of applications monitoring lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signal about network loss is u= seful, rather than applications using arbitrary timeouts on transaction tim= es. 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.

-     &= nbsp;    Having said that, the application should not have t= o know about links or layer2 health.

-     &= nbsp;    Links should be able to go up and down, without dro= pping 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.

-     &= nbsp;    but one thing that warrants an exception is when th= e 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 l= onger available on the host, presumably in the hope that the IP address will be assigned again.

 

-     &= nbsp;     The socket should only fail if the transactio= n 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).

-     &= nbsp;    Typical applications will connect with “any&#= 8221; for the source address to bind to. When a host has multiple IP addres= ses (multi-homed), there is a complicated set of rules for choosing one (RF= C 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 compa= tible:

-     &= nbsp;    Add an ioctl or getsockopt so that the application = can ask, “would there be a better choice of local address”, giv= ing the application an opportunity to start another socket at the best oppo= rtunity (after the current transaction).

-     &= nbsp;    Add a socket option for the idea of “create s= ocket error if local IP has been lost for X seconds”. I propose the t= imeout, allowing an IP address to be removed from one interface and added t= o another without socket error. This is better than an application timeout.

 

Consider the case of a database client using a persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_E8355113905631478EFF04F5AA706E9830CB925Dwtlexchp1sandvi_-- From nobody Wed Aug 12 11:35:13 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A811A21B3 for ; Wed, 12 Aug 2015 11:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm_xswVHYdzq for ; Wed, 12 Aug 2015 11:35:10 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8B01A1A1B for ; Wed, 12 Aug 2015 11:35:10 -0700 (PDT) Received: by pabyb7 with SMTP id yb7so19752089pab.0 for ; Wed, 12 Aug 2015 11:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=iPHOgEvSZrtODxY9Zx/YYxtPf02SV6FjlsU9783pgLA=; b=W6bhLUYgmiXDCzeyLx6HQ4ow2Lm1sk9TpakcPlnqnohD3TRkHuaa7rQFoFxdAyU/F0 e9l0muT5wSJmfDqgASlCKW4OG2i2k9K8t3ae2IR/EItmEabEvN+D9OVU1J9qu7s/q16O IDrwQ1N+8FIdwStEGpN/Hn6gMTjY/AI5EuyQlp92lKXB8Q48XDbHWhKLheD7VjuIc/Vu 19DIAF64hhm3VLtGNMDgLQgSx6zjO/6gRCZIMLrOiL/Os9UQDoFuc22B+j+2vvYXVTuZ bjjxqLfZKeme7tYngUl9dnLn2VNUlUc3yh2/VJ6i58n/SFX3KtNdd3bpjrFDzlmwbmEJ j55w== X-Received: by 10.68.243.103 with SMTP id wx7mr22657416pbc.60.1439404510304; Wed, 12 Aug 2015 11:35:10 -0700 (PDT) Received: from [10.16.10.148] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id tt8sm7262247pbc.49.2015.08.12.11.35.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2015 11:35:09 -0700 (PDT) To: "dmm@ietf.org" From: Jouni Korhonen Message-ID: <55CB91DB.3030509@gmail.com> Date: Wed, 12 Aug 2015 11:35:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DMM] WG Last Call for draft-ietf-dmm-4283mnids-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:35:12 -0000 Folks, This mail starts a two week WGLC #1 for the I-D draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific time. Please, review the document and indicate your support or concerns on the mailing list. If you have concerns or comments that you want to be reflected in the draft text issue a ticket into the issue tracker as well. We urge you to utilize the issue tracker for comments that you want to be resolved. - Dapeng and Jouni From nobody Wed Aug 12 23:42:24 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C891A01EA for ; Wed, 12 Aug 2015 23:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHcLJFEHimtN for ; Wed, 12 Aug 2015 23:42:16 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 069F21A017E for ; Wed, 12 Aug 2015 23:42:16 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 12 Aug 2015 23:42:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,667,1432623600"; d="scan'208,217";a="747649183" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga001.jf.intel.com with ESMTP; 12 Aug 2015 23:42:12 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 13 Aug 2015 07:42:11 +0100 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by IRSMSX156.ger.corp.intel.com (10.108.20.68) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 13 Aug 2015 07:42:11 +0100 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.53]) by LCSMSX154.ger.corp.intel.com ([169.254.7.39]) with mapi id 14.03.0224.002; Thu, 13 Aug 2015 09:42:10 +0300 From: "Moses, Danny" To: Dave Dolson , John Kaippallimalil Thread-Topic: mobility and link state [- re: prefix cost] Thread-Index: AQHQ1S0LtpJA19jWlk+v7iUzUql3EZ4JdRig Date: Thu, 13 Aug 2015 06:42:08 +0000 Message-ID: References: <6561EABF52675C45BCDACA1B4D7AA1171DB032ED@dfweml703-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2813495EC4FHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state [- re: prefix cost] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 06:42:23 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2813495EC4FHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 addres= s change - I agree that this is the most useful one 2. To be able to postpone sending packets when the link is down (assu= ming it is a temporary state) to prevent TCP time-outs (or other higher-lev= el phenomena which could occur with UDP-based traffic) 3. To trigger a refresh of the source IP address in case of a potenti= al triangle route as a result of a handoff (I tried to describe this in the= scenario named: "Handoff - Sustained address - new LAN - better service av= ailable" in slides 15-16). I agree that there are different events that influence a change in the sour= ce 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 ap= plications to better specify their needs and have the network fulfill these= needs. For example: App wants IP session continuity, so it requests a Sust= ained 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 a= pplications 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 n= etwork about different paths and costs and makes intelligent decisions base= d 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 applicatio= n developers. /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, August 12, 2015 21:31 To: John Kaippallimalil; Moses, Danny Cc: dmm@ietf.org 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 t= he 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:John.Kaippallimalil@huawei.com] Sent: Wednesday, August 12, 2015 2:18 PM To: Dave Dolson; Moses, Danny Cc: dmm@ietf.org Subject: RE: mobility and link state [- re: prefix cost] Dave, With reference to "Suppose an application could find out about the differen= t IP addresses available to it, and the costs & attributes of using each. W= ouldn'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 (bet= ween 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 wil= l be updating soon. One of the comments was regarding how the host (and app= lication) can use this information. Best Regards, John From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, August 12, 2015 7:53 AM To: Moses, Danny Cc: dmm@ietf.org 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 abou= t link state per se, rather about source IP changes. Suppose an application could find out about the different IP addresses avai= lable to it, and the costs & attributes of using each. Wouldn't that fulfil= l 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 int= erface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.moses@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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms. /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_F0CF5715D3D1884BAC731EA1103AC2813495EC4FHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

This is turning to be = an interesting discussion.

 

Regarding Dave's reply= (before John reply):

Actually, there are se= veral motivations for indications from the link layer:

1.&n= bsp;      As Dave pointed out in his reply – to be aware of source I= P address change – I agree that this is the most useful one

2.&n= bsp;      To be able to postpone sending packets when the link is down (as= suming it is a temporary state) to prevent TCP time-outs (or other higher-l= evel phenomena which could occur with UDP-based traffic)

3.&n= bsp;      To trigger a refresh of the source IP address in case of a poten= tial triangle route as a result of a handoff (I tried to describe this in t= he scenario named: "Handoff – Sustained address – new LAN – better service available" in slides 1= 5-16).

I agree that there are= different events that influence a change in the source IP address which co= uld affect applications and I am still not sure what is the preferable leve= l of exposure to them.

 

Regarding John's comme= nt:

The work done so far i= n the exposure WT was more in the area of enabling applications to better s= pecify their needs and have the network fulfill these needs. For example: A= pp wants IP session continuity, so it requests a Sustained address and the network allocates one. The applicatio= n is not exposed to the details of supporting IP session continuity and tha= t is good.

 

The link-state exposur= e 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 mob= ility 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 t= o the level of awareness they require from application developers.

 

/Danny

 

 

From: Dave Dol= son [mailto:ddolson@sandvine.com]
Sent: Wednesday, August 12, 2015 21:31
To: John Kaippallimalil; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Yes, (by reading the a= bstract) 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 t= o bind to, without having to know anything about the access technology.

Go no lower than the I= P layer. Applications shouldn’t have to know about 3G or LTE or WiFi = or 100baseT or VPN connections…

 

 

 

From: John Kai= ppallimalil [mailto:John.= Kaippallimalil@huawei.com]
Sent: Wednesday, August 12, 2015 2:18 PM
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Dave,

With reference to R= 20;Suppose an application could find o= ut about the different IP addresses available to it, and the costs & at= tributes of using each. Wouldn’t that fulfill the use case in a very general manner?= 221;

 

Pete and I have a draf= t - http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addre= sses 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 nu= mber of comments during the IETF presentation and will be updating soon. On= e of the comments was regarding how the host (and application) can use this= information.

 

Best Regards,

John=

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: dmm@ietf.org
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, r= ather about source IP changes.

 

Suppose an application= could find out about the different IP addresses available to it, and the c= osts & attributes of using each. Wouldn’t that fulfill the use ca= se 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 cryptogra= phically-generated IPv6 addresses

- multi-homing changes= , such as *adding* a WiFi interface without dropping a mobile interf= ace.

 

I note also that BSD a= llows IP addresses to be assigned to the loopback interface, the state of w= hich never changes.

 

-Dave

 

 

 

From: Moses, D= anny [mailto:danny.moses@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 commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering means for applications to be mobility aware on their choice to enable= them to behave in a more optimal manner in mobile platforms.

 

/Danny

 

 

Danny,

Although I’m new to this working group, today = I watched you present at IETF on the subject of applications monitoring lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signa= l about network loss is useful, rather than applications using arbitrary ti= meouts on transaction times. Example: when should a browser or database cli= ent give up on a request? The timeout approach is unsatisfactory for transactions that take a long time to run.<= o:p>

-     &= nbsp;    Having said that, the appl= ication should not have to know about links or layer2 health.

-     &= nbsp;    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 sock= et.

-     &= nbsp;    but one thing that warrant= s an exception is when the address bound by the socket is no longer availab= le on the host. I believe current behavior a socket will stay alive even wh= en the IP address is no longer available on the host, presumably in the hope that the IP address will be assigned a= gain.

 

-     &= nbsp;     The socket should on= ly 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 &#= 8220;permanent”? --> need heuristics).

-     &= nbsp;    Typical applications will = connect with “any” for the source address to bind to. When a ho= st has multiple IP addresses (multi-homed), there is a complicated set of r= ules for choosing one (RFC 6724). Your thoughts on choosing best routes may fit in this framework. (Is RFC 5014 relevant h= ere?)

 

So my proposal, which I think can be backwards compa= tible:

-     &= nbsp;    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 anothe= r socket at the best opportunity (after the current transaction).

-     &= nbsp;    Add a socket option for th= e idea of “create socket error if local IP has been lost for X second= s”. 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 persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_F0CF5715D3D1884BAC731EA1103AC2813495EC4FHASMSX106gercor_-- From nobody Thu Aug 13 07:36:20 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D621A6EDA for ; Thu, 13 Aug 2015 07:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TcbOUZwHnKa for ; Thu, 13 Aug 2015 07:36:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445121A21BC for ; Thu, 13 Aug 2015 07:36:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF29773; Thu, 13 Aug 2015 14:36:06 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 13 Aug 2015 15:36:05 +0100 Received: from DFWEML703-CHM.china.huawei.com ([10.193.5.130]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Thu, 13 Aug 2015 07:35:58 -0700 From: John Kaippallimalil To: "Moses, Danny" , Dave Dolson Thread-Topic: mobility and link state [- re: prefix cost] Thread-Index: AQHQ1Ss2zAYbSZ8GbEmydQYfMGN3QJ4JJQgAgADMUwCAAAYeEA== Date: Thu, 13 Aug 2015 14:35:57 +0000 Message-ID: <6561EABF52675C45BCDACA1B4D7AA1171DB0448D@dfweml703-chm> References: <6561EABF52675C45BCDACA1B4D7AA1171DB032ED@dfweml703-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.71] Content-Type: multipart/alternative; boundary="_000_6561EABF52675C45BCDACA1B4D7AA1171DB0448Ddfweml703chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dmm@ietf.org" Subject: Re: [DMM] mobility and link state [- re: prefix cost] X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:36:18 -0000 --_000_6561EABF52675C45BCDACA1B4D7AA1171DB0448Ddfweml703chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danny, Some thoughts and clarifications : * "As Dave pointed out in his reply - to be aware of source IP addr= ess 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 dec= isions based on that information" The draft on prefix-cost assumes that the application can be informed by th= e 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 wa= nt application level continuity insert an new socket option, and poll the n= etwork 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), o= r 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 des= cribes how a host can learn the network "costs" per IP prefix. However, th= e 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 revisio= n of the draft and suggestions/input is welcome. BR, John From: Moses, Danny [mailto:danny.moses@intel.com] Sent: Thursday, August 13, 2015 1:42 AM To: Dave Dolson; John Kaippallimalil Cc: dmm@ietf.org Subject: RE: mobility and link state [- re: prefix cost] 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 addres= s change - I agree that this is the most useful one 2. To be able to postpone sending packets when the link is down (assu= ming it is a temporary state) to prevent TCP time-outs (or other higher-lev= el phenomena which could occur with UDP-based traffic) 3. To trigger a refresh of the source IP address in case of a potenti= al triangle route as a result of a handoff (I tried to describe this in the= scenario named: "Handoff - Sustained address - new LAN - better service av= ailable" in slides 15-16). I agree that there are different events that influence a change in the sour= ce 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 ap= plications to better specify their needs and have the network fulfill these= needs. For example: App wants IP session continuity, so it requests a Sust= ained 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 a= pplications 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 n= etwork about different paths and costs and makes intelligent decisions base= d 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 applicatio= n developers. /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Wednesday, August 12, 2015 21:31 To: John Kaippallimalil; Moses, Danny Cc: dmm@ietf.org 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 t= he 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:John.Kaippallimalil@huawei.com] Sent: Wednesday, August 12, 2015 2:18 PM To: Dave Dolson; Moses, Danny Cc: dmm@ietf.org Subject: RE: mobility and link state [- re: prefix cost] Dave, With reference to "Suppose an application could find out about the differen= t IP addresses available to it, and the costs & attributes of using each. W= ouldn'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 (bet= ween 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 wil= l be updating soon. One of the comments was regarding how the host (and app= lication) can use this information. Best Regards, John From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson Sent: Wednesday, August 12, 2015 7:53 AM To: Moses, Danny Cc: dmm@ietf.org 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 abou= t link state per se, rather about source IP changes. Suppose an application could find out about the different IP addresses avai= lable to it, and the costs & attributes of using each. Wouldn't that fulfil= l 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 int= erface, the state of which never changes. -Dave From: Moses, Danny [mailto:danny.moses@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 worl= d (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 co= nnection loss is temporary and lasts for a very short amount of time, and t= he 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 t= ransparent 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 sourc= e IP address change. This ability means that they do not benefit from the n= etwork's IP session continuity support, but still have to suffer from the i= nherit overhead. To resolve this, we introduced the 'On-Demand' concept in = which applications have the ability to indicate to the NW their desire to r= eceive 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). W= e believe that in the mobile world, application developers may benefit from= being aware of the mobility behavior of the platform on which their applic= ations are deployed. They do not have to be, but being aware can yield bett= er performance (same goes for energy consumption - but this is out of the s= cope of DMM). To conclude, we are not requiring all future applications to be mobility-aw= are. We are offering means for applications to be mobility aware on their c= hoice to enable them to behave in a more optimal manner in mobile platforms= . /Danny From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Tuesday, July 21, 2015 02:52 To: Moses, Danny Cc: 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 c= onnection, 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 phys= ical interface to a tunnel interface) without interruption of the socket. - but one thing that warrants an exception is when the address bou= nd by the socket is no longer available on the host. I believe current beha= vior a socket will stay alive even when the IP address is no longer availab= le 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 addr= ess 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, "wou= ld there be a better choice of local address", giving the application an op= portunity to start another socket at the best opportunity (after the curren= t transaction). - Add a socket option for the idea of "create socket error if loca= l IP has been lost for X seconds". I propose the timeout, allowing an IP ad= dress 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 connecti= on 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 presumabl= y 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. --_000_6561EABF52675C45BCDACA1B4D7AA1171DB0448Ddfweml703chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Danny,

Some thoughts and clar= ifications :

·         “= As Dave pointed out in his reply – to b= e aware of source IP address change – I agree that this is the most u= seful 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= 217;s draft goes one step further: It assumes that application query the ne= twork 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 prefer= able IP address. Applications that do not need this operate as they do toda= y. The subset of applications that want application level continuity insert an new socket option, and poll th= e network stack/OS for this information. It would be application behavior a= nd 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 des= cribes how a host can learn the network “costs” per IP prefix.&= nbsp; 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/i= nput is welcome.

 

BR,<= /p>

John=

 

From: Moses, D= anny [mailto:danny.moses@intel.com]
Sent: Thursday, August 13, 2015 1:42 AM
To: Dave Dolson; John Kaippallimalil
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Hi,<= /p>

 

This is turning to be = an interesting discussion.

 

Regarding Dave's reply= (before John reply):

Actually, there are se= veral motivations for indications from the link layer:

1.&n= bsp;      As Dave pointe= d out in his reply – to be aware of source IP address change – = I agree that this is the most useful one

2.&n= bsp;      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 coul= d occur with UDP-based traffic)

3.&n= bsp;      To trigger a r= efresh 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 co= uld affect applications and I am still not sure what is the preferable leve= l of exposure to them.

 

Regarding John's comme= nt:

The work done so far i= n the exposure WT was more in the area of enabling applications to better s= pecify their needs and have the network fulfill these needs. For example: A= pp wants IP session continuity, so it requests a Sustained address and the network allocates one. The applicatio= n is not exposed to the details of supporting IP session continuity and tha= t is good.

 

The link-state exposur= e 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 mob= ility 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 t= o the level of awareness they require from application developers.

 

/Danny

 

 

From: Dave Dol= son [mailto:ddolson@sandvine.com]
Sent: Wednesday, August 12, 2015 21:31
To: John Kaippallimalil; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Yes, (by reading the a= bstract) 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 t= o bind to, without having to know anything about the access technology.

Go no lower than the I= P layer. Applications shouldn’t have to know about 3G or LTE or WiFi = or 100baseT or VPN connections…

 

 

 

From: John Kai= ppallimalil [mailto:John.= Kaippallimalil@huawei.com]
Sent: Wednesday, August 12, 2015 2:18 PM
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: mobility and link state [- re: prefix cost]<= /span>

 

Dave,

With reference to R= 20;Suppose an application could find o= ut about the different IP addresses available to it, and the costs & at= tributes of using each. Wouldn’t that fulfill the use case in a very general manner?= 221;

 

Pete and I have a draf= t - http://datatracker.ietf.org/doc/draft-mccann-dmm-prefixcost/ that addre= sses 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 nu= mber of comments during the IETF presentation and will be updating soon. On= e of the comments was regarding how the host (and application) can use this= information.

 

Best Regards,

John=

 

 

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Wednesday, August 12, 2015 7:53 AM
To: Moses, Danny
Cc: dmm@ietf.org
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, r= ather about source IP changes.

 

Suppose an application= could find out about the different IP addresses available to it, and the c= osts & attributes of using each. Wouldn’t that fulfill the use ca= se 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 cryptogra= phically-generated IPv6 addresses

- multi-homing changes= , such as *adding* a WiFi interface without dropping a mobile interf= ace.

 

I note also that BSD a= llows IP addresses to be assigned to the loopback interface, the state of w= hich never changes.

 

-Dave

 

 

 

From: Moses, D= anny [mailto:danny.moses@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 commen= ts.

In general, I agree th= at 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 mobil= e).

 

With the introduction = of mobile platforms, the event of a temporary loss of connection is much mo= re common (as a result of handoffs). Still, if the connection loss is tempo= rary 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 c= ould still be transparent to applications.

 

But maintaining the so= urce IP address (which is referred to in some drafts as: 'IP session contin= uity') come with a price: Maintaining tunnels, extra encapsulation header i= n each packet, non-optimal routes etc…

 

We have acknowledged t= hat some applications can easily recover from a source IP address change. T= his ability means that they do not benefit from the network's IP session co= ntinuity support, but still have to suffer from the inherit overhead. To resolve this, we introduced the 'On-D= emand' 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 ch= ange 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 w= hich 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 no= t requiring all future applications to be mobility-aware. We are off= ering means for applications to be mobility aware on their choice to enable= them to behave in a more optimal manner in mobile platforms.

 

/Danny

 

 

Danny,

Although I’m new to this working group, today = I watched you present at IETF on the subject of applications monitoring lin= k state.

You asked for feedback on the mailing list… Ma= ybe some of these ideas are useful:

 

Thinking as an application author,

-     &= nbsp;    I think some kind of signal about network loss is u= seful, rather than applications using arbitrary timeouts on transaction tim= es. 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.

-     &= nbsp;    Having said that, the application should not have t= o know about links or layer2 health.

-     &= nbsp;    Links should be able to go up and down, without dro= pping 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.

-     &= nbsp;    but one thing that warrants an exception is when th= e 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 l= onger available on the host, presumably in the hope that the IP address will be assigned again.

 

-     &= nbsp;     The socket should only fail if the transactio= n 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).

-     &= nbsp;    Typical applications will connect with “any&#= 8221; for the source address to bind to. When a host has multiple IP addres= ses (multi-homed), there is a complicated set of rules for choosing one (RF= C 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 compa= tible:

-     &= nbsp;    Add an ioctl or getsockopt so that the application = can ask, “would there be a better choice of local address”, giv= ing the application an opportunity to start another socket at the best oppo= rtunity (after the current transaction).

-     &= nbsp;    Add a socket option for the idea of “create s= ocket error if local IP has been lost for X seconds”. I propose the t= imeout, allowing an IP address to be removed from one interface and added t= o another without socket error. This is better than an application timeout.

 

Consider the case of a database client using a persi= stent database connection for queries.

To handle the soft hand-over case a smart client wou= ld keep checking if the socket is optimal. If not, finish the current trans= action on the existing socket and open a new socket for new transactions. T= he 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.

--_000_6561EABF52675C45BCDACA1B4D7AA1171DB0448Ddfweml703chm_-- From nobody Tue Aug 18 11:43:45 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7B21A0053 for ; Tue, 18 Aug 2015 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQSXP-bdg0Yf for ; Tue, 18 Aug 2015 11:43:42 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9072C1A002A for ; Tue, 18 Aug 2015 11:43:42 -0700 (PDT) Received: by paccq16 with SMTP id cq16so94697848pac.1 for ; Tue, 18 Aug 2015 11:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=S3kVsrpYJQC50y8tTZ+K8yZoSzCFO2AV8rUqwfmkQl8=; b=mLzxrhBpxesodfCV4CD2N/CDcjZIgBCrA/3jdMClR1ngJB8Aet/nsJuQnNce9710OR OFGnGA1F/eE4uRmdTuwMU6Vn4NChyiZll/IdhBmPPyKLjhMVvbWJHt+448DDEPTa6f6x /BrL3JTyLrs9PfokZQUJoNmTgblWhgoMvHXxzAWgaW6nRb9RUUTNooP/TRbKVHO2ulaU g97T++/v7FBeU7Ri/k12mIXVZoZWF7KZcK9n4oXqDA74JCENvJpQEb2i+1MSCu0lFef3 ekSP95NwCWyApRUaunCLHa3vitpTzhKfFnN/tjV9ujc4hwtPUL2G6MM4TUGTApHyCMmu kLHA== X-Received: by 10.66.182.161 with SMTP id ef1mr15840292pac.97.1439923422323; Tue, 18 Aug 2015 11:43:42 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:d5a2:2855:8297:4b1c? ([2601:647:4204:228b:d5a2:2855:8297:4b1c]) by smtp.googlemail.com with ESMTPSA id is3sm18867057pbc.53.2015.08.18.11.43.41 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Aug 2015 11:43:41 -0700 (PDT) To: "dmm@ietf.org" References: <55CB91DB.3030509@gmail.com> From: Jouni Korhonen Message-ID: <55D37CDD.5030108@gmail.com> Date: Tue, 18 Aug 2015 11:43:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55CB91DB.3030509@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] WG Last Call for draft-ietf-dmm-4283mnids-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 18:43:43 -0000 A friendly reminder. - Jouni & Dapeng 8/12/2015, 11:35 AM, Jouni Korhonen kirjoitti: > Folks, > > This mail starts a two week WGLC #1 for the I-D > draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific > time. > > Please, review the document and indicate your support or concerns on the > mailing list. If you have concerns or comments that you want to be > reflected in the draft text issue a ticket into the issue tracker as > well. We urge you to utilize the issue tracker for comments that you > want to be resolved. > > - Dapeng and Jouni From nobody Tue Aug 18 12:51:46 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52D91A9150 for ; Tue, 18 Aug 2015 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlUpVDsL9FtT for ; Tue, 18 Aug 2015 12:51:44 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 46BE21A9152 for ; Tue, 18 Aug 2015 12:51:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iA9fRdrl1ZJBGATKsTIskl5wU3iWsuQSIwTZyIWRMhQqTdJCwQS70XMPoWSVkKwV; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.253.145]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ZRmv4-0007jG-1J; Tue, 18 Aug 2015 15:51:38 -0400 To: Jouni Korhonen , "dmm@ietf.org" References: <55CB91DB.3030509@gmail.com> <55D37CDD.5030108@gmail.com> From: Charlie Perkins Message-ID: <55D38CC3.9030300@earthlink.net> Date: Tue, 18 Aug 2015 12:51:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D37CDD.5030108@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7bbd4da9996c91fbabade969b10d398cb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Subject: Re: [DMM] WG Last Call for draft-ietf-dmm-4283mnids-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 19:51:46 -0000 Hello Jouni, I think the document is pretty straightforward, and offers a useful facility. New MN ID types can be added in the future. Disclaimer - I am a co-author of the document. Regards, Charlie P. On 8/18/2015 11:43 AM, Jouni Korhonen wrote: > A friendly reminder. > > - Jouni & Dapeng > > 8/12/2015, 11:35 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> This mail starts a two week WGLC #1 for the I-D >> draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific >> time. >> >> Please, review the document and indicate your support or concerns on the >> mailing list. If you have concerns or comments that you want to be >> reflected in the draft text issue a ticket into the issue tracker as >> well. We urge you to utilize the issue tracker for comments that you >> want to be resolved. >> >> - Dapeng and Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Aug 21 15:50:18 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9761ACEED; Fri, 21 Aug 2015 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3HYq0kGm1BO; Fri, 21 Aug 2015 15:50:13 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A551ACED1; Fri, 21 Aug 2015 15:50:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t7LMoEk7001433; Fri, 21 Aug 2015 17:50:14 -0500 Received: from XCH-BLV-508.nw.nos.boeing.com (xch-blv-508.nw.nos.boeing.com [130.247.25.198]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t7LMo3q2001377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 21 Aug 2015 17:50:04 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.231]) by XCH-BLV-508.nw.nos.boeing.com ([169.254.8.226]) with mapi id 14.03.0235.001; Fri, 21 Aug 2015 15:50:01 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" , "int-area@ietf.org" Thread-Topic: AERO source code available Thread-Index: AdDcYxUzKU0i88J3R5yo/7BlaM/nGA== Date: Fri, 21 Aug 2015 22:50:00 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832EE5F7D@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [DMM] AERO source code available X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 22:50:17 -0000 Hello, AERO (draft-templin-aerolink) has been under internal development for some time, and is now available for first public release: http://linkupnetworks.org/aero/aero-3.0.1.tgz https://datatracker.ietf.org/doc/draft-templin-aerolink/ This release includes a user-level daemon for use on AERO Clients and Servers, and a kernel-level driver for use on AERO Relays. Also included ar= e network emulation models of simple AERO networks for experimentation using the Common Open Research Emulator (CORE): http://www.nrl.navy.mil/itd/ncs/products/core The code has been tested primarily on Ubuntu, but can be ported to other linux-based platforms. Android testing should also be possible. This release currently demonstrates the following aspects of AERO: - AERO tunnel virtual NBMA link - DHCPv6 Prefix Delegation (PD) - IPv6 Neighbor Discovery (ND) - BGP routing - AERO Client to Internet host communications - AERO Client to AERO Client route optimization - AERO Client mobility Guidance can be found in README files and manpages; please feel free to experiment with the code and send feedback. We will address any issues and introduce new functionality in follow-on releases in a timely fashion. Fred Templin fred.l.etmplin@boeing.com From nobody Fri Aug 28 04:45:42 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B981B2F65 for ; Fri, 28 Aug 2015 04:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D344n6yUEnhn for ; Fri, 28 Aug 2015 04:45:40 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30621B2F11 for ; Fri, 28 Aug 2015 04:45:39 -0700 (PDT) Received: by pacdd16 with SMTP id dd16so60606625pac.2 for ; Fri, 28 Aug 2015 04:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=sTXvL312fHKdOxPhwTEx84M17ZQonbyEPhTsih8A6zc=; b=aiv23duYlq4oqKL9kP0cbsqkU41ov4gXKfEFywgYXFu1OGnO5LrLpHZIQqFbt5q07g x4sGXTn7T66TPmM8vEaGvBXlJiNsko2RslxYFgGOYxCM9L4AYPW4c5h5g7/bJ51uNmH+ G1Y4X/myl0DQQtRjn7N1bA02YOdHYwVCB1g9/mKR9P+FA8e4o2hSiBBrIV5/OTouWWD2 C4lGAj/USiMzgCnKxdboIjI1VuH13qG/6uJsFE/tB8HU09rlKPk6tHs5VShtSDKwqqiI 7TPMAYqHXp4H/Ho7+DFwaKC0jSuV2GlXIgXrUu2CPsktGwkw+gNbMlIkEr313jQRuLO2 Ig6w== X-Received: by 10.68.224.162 with SMTP id rd2mr14577347pbc.33.1440762339516; Fri, 28 Aug 2015 04:45:39 -0700 (PDT) Received: from [10.0.1.6] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id fm5sm5502409pbb.60.2015.08.28.04.45.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Aug 2015 04:45:38 -0700 (PDT) From: Jong-Hyouk Lee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2015 20:45:33 +0900 To: dmm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [DMM] Review request for the Home Network Prefix Renumbering in PMIPv6 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 11:45:41 -0000 Hi all Kindly consider to review the draft "Home Network Prefix Renumbering in = PMIPv6": https://datatracker.ietf.org/doc/draft-yan-dmm-hnprenum/ Before = the WG adoption call, authors are willing to get further comments and = improve the draft. J.=20 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon From nobody Mon Aug 31 14:32:09 2015 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9A21B645F for ; Mon, 31 Aug 2015 14:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1RO2wF6GXMp for ; Mon, 31 Aug 2015 14:32:07 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F150A1B645A for ; Mon, 31 Aug 2015 14:32:06 -0700 (PDT) Received: by pabzx8 with SMTP id zx8so151525152pab.1 for ; Mon, 31 Aug 2015 14:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=ovmGu17nNF8ZI02zZ3N9Hr+TOmrj2kQ08JvW9YIQtX0=; b=lYhUBo+eR7X6GeQXodcN8McKnAWNCAPmbYCcr1G98cmWxeiD/buXkRT71prq11tDn4 piV9pRWWbHiipAJi38YJLe6/BVZMA47oC6sjlhL9Vykug0CR3dLKvdKfxY9zu+Kw1m+G 8RA6ADlRH8YR6B4dVyMaA3koEUKcbjMw80KHR8ldcgPjcHY7MibPQoibDmsdvIPOudep R7+HpYNnM/xOhp+g0kOO+zCQ3y3++eDQRZBiQ4Wb5Xi2WmQYagfCGcsVMkuFdiV7UoWY +pi/aVWIy/jqEwN+CVZAft8B8r7Wigam1erBd+K64N6CtvXBQLWxpYvZkxM4QG9eSvhi EZEg== X-Received: by 10.68.200.40 with SMTP id jp8mr42253603pbc.16.1441056726557; Mon, 31 Aug 2015 14:32:06 -0700 (PDT) Received: from [10.16.11.111] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id y9sm4137392pdp.17.2015.08.31.14.32.04 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Aug 2015 14:32:05 -0700 (PDT) To: "dmm@ietf.org" References: <55CB91DB.3030509@gmail.com> <55D37CDD.5030108@gmail.com> From: Jouni Korhonen Message-ID: <55E4C7D3.3070902@gmail.com> Date: Mon, 31 Aug 2015 14:32:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55D37CDD.5030108@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DMM] WG Last Call for draft-ietf-dmm-4283mnids-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:32:08 -0000 Folks, We got only one "review" and that being from the author. I cannot consider the I-D passed the WGLC. I will initiate another WGLC soon. - Jouni & Dapeng 8/18/2015, 11:43 AM, Jouni Korhonen kirjoitti: > A friendly reminder. > > - Jouni & Dapeng > > 8/12/2015, 11:35 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> This mail starts a two week WGLC #1 for the I-D >> draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific >> time. >> >> Please, review the document and indicate your support or concerns on the >> mailing list. If you have concerns or comments that you want to be >> reflected in the draft text issue a ticket into the issue tracker as >> well. We urge you to utilize the issue tracker for comments that you >> want to be resolved. >> >> - Dapeng and Jouni