Arif Ahmed

Guillaume Pierre

Docker-pi: Docker Container Deployment in Fog Computing Infrastructures

The transition from virtual machine-based infrastructures to containerbased ones brings the promise of swift and efficient software deployment in large-scale computing infrastructures. However, in fog computing environments which are often made of very small computers such as Raspberry PIs, deploying even a very simple Docker container may take multiple minutes. We demonstrate that Docker makes inefficient usage of the available hardware resources, essentially using different hardware subsystems (network bandwidth, CPU, disk I/O) sequentially rather than simultaneously. We therefore propose three optimizations which, once combined, reduce container deployment times by a factor up to 4. These optimizations also speed up deployment time by about 30% in datacenter-grade servers.

Introduction

Fog computing extends datacenter-based cloud platforms with additional resources located in the immediate vicinity of the end users. By bringing computation where the input data was produced and the resulting output data will be consumed, fog computing is expected to support new types of applications which either require very low network latency to their end users (e.g., augmented reality applications) or produce large volumes of data which are relevant only locally (e.g., IoT-based data analytics).

Fog computing architectures are fundamentally different from classical cloud platforms: to provide computing resources in the physical vicinity of any end user, fog computing platforms must necessarily rely on very large numbers of small Points-of-Presence connected to each other with commodity networks, whereas clouds are typically organized with a handful of extremely powerful data centers connected by dedicated ultra-high-speed networks. This geographical spread also implies that the machines used in any Point-of-Presence may not be datacenter-grade servers but much weaker commodity machines. As a matter of fact, one option which is being explored is to use single-board computers such as Raspberry PIs for this purpose. Despite their obvious hardware limitations, Raspberry PIs offer excellent performance/cost/energy ratios and are 1 well-suited to scenarios where the device's physical size and energy consumption are important enablers for actual deployment [START_REF] Van Kempen | MEC-ConPaaS: An experimental single-board based mobile edge cloud[END_REF][START_REF] Hajji | Understanding the performance of low power Raspberry Pi cloud for big data[END_REF].

However, building a high-performance fog platform based on tiny singleboard computers remains a difficult challenge: in particular these machines have very limited I/O performance. In this paper, we focus on the issue of downloading and deploying Docker containers in single-board computers. We assume that server machines have limited storage capacity and therefore cannot be expected to keep in cache the container images of many applications that may be used simultaneously in a public fog computing infrastructure.

Deploying container images can be painfully slow, in the order of multiple minutes depending on the container's image size and network condition. However, such delays are unacceptable in scenarios such as a fog-assisted augmented reality application where the end users are mobile and new containers must be dynamically created when a user enters a new geographical area. Reducing deployment times as much as possible is therefore instrumental in providing a satisfactory user experience.

We show that this poor performance is not only due to hardware limitations. In fact it largely results from the way Docker implements the container's image download operation: (a) Docker downloads multiple image layers in parallel and then extracts the layers sequentially starting from the first layer. However, downloading the layers in parallel delays the download process of the first layer and therefore, postpones the moment its decompression and extraction phase can start. Therefore, delaying the downloading of the first layer ultimately leads to slowing down the extraction phase; (b) Docker image layers are shipped as compressed tar files. Upon downloading an image file, Docker decompresses it using single-threaded decompression gzip which account only for ∼37% CPU utilization of all the machine's cores. A significant amount of deployment time is spent in decompressing the layers; (c) Each image layer is sequentially downloaded, decompressed and extracted to disk. In other words, there is very little overlapping between the three activities of the different hardware resources (i.e. network, CPU and disk) while deploying the image. Docker exploits different hardware subsystems (network bandwidth, CPU, disk I/O) sequentially rather than simultaneously.

We therefore propose three optimization techniques which aim to improve the level of parallelism of the deployment process. Each technique reduces deployment times by 10-50% depending on the content and structure of the container's image and the available network bandwidth. When combined together, the resulting "Docker-pi" implementation makes container deployment up to 4 times faster than the vanilla Docker implementation, while remaining totally compatible with unmodified Docker images.

Interestingly, although we designed Docker-pi in the context of single-board computers, it also provides 23-36% performance improvements on high-end servers as well, depending on the image size and organization.

This paper is an extended version of a previous conference paper [START_REF] Ahmed | Docker Container Deployment in Fog Computing Infrastructures[END_REF]. The additional contributions of this article are as follows: (i) We evaluate the resource utilization when deploying three different Docker images and thereby illustrate the influence of image structure on the performance of each optimization solution (Sections 3-4); (ii) We compare the memory footprint of Docker-pi and standard Docker while deploying container images, and demonstrate that Docker-pi consumes much less memory that regular Docker during image installation (Section 4.4.2); (iii) We evaluate the impact of deploying a Docker image on the performance of an already-running application in the same machine (Section 4.4.3).

This paper is organized as follows. Section 2 presents the background and related work. Section 3 analyzes the deployment process and points out its inefficiencies. Section 4 proposes and evaluates three optimizations. Finally, Section 5 discusses practicalities, and Section 6 concludes.

Background

Docker background

Docker is a popular framework to build, package, and run applications inside containers [START_REF] Inc | Docker: Build, ship, and run any app[END_REF]. Applications are packaged in the form of images which contain a part of a file system with the required libraries, executables, configuration files, etc. Images are stored in centralized repositories where they are accessible from any compute server. To deploy a container, Docker therefore first downloads the image from the repository and locally installs it, unless the image is already cached in the compute node. Starting a container from a locally-installed image is as quick as starting the processes which constitute the container's application. The deployment time of any container is therefore dictated by the time it takes to download, decompress, verify, and locally install the image before starting the container itself.

Image structure

Docker images are composed of multiple layers stacked upon one another: every layer may add, remove, or overwrite files present in the layers below itself. This enables developers to build new images very easily by simply specializing preexisting images.

The same layering strategy is also used to store file system updates performed by the applications after a container has started: upon every container deployment, Docker creates an additional writable top-level layer which stores all updates following a Copy-on-Write (CoW) policy. The container's image layers themselves remain read-only. Table 1 shows the structures of the three images used in this paper.

Figure 1 shows a typical image which consists of 7 layers. The first five layers represent a standard Ubuntu Linux image: the first layer holds most of the contents (46 MB in compressed form), and the other layers are much smaller specializations such as updates of some specific packages and/or configuration files. In this example, we further extended Ubuntu into a so-called "Mubuntu" image with an extra 51 MB layer representing a hypothetical application's executable and data. Finally, Layer 7 stores any file system update which may be issued by the application during its execution. Each layer is stored in the registry as a simple compressed tar file.

Container deployment process

Docker images are identified with a name and a tag representing a specific version of the image. Docker users can start any container by simply giving its name and tag using the command: docker run IMAGE:TAG [parameters] Docker keeps a copy of the latest deployed images in a local cache. When a user starts a container, there are four possible cases depending on the contents of this cache:

• The image is not available. In this case the image must be downloaded from the Docker registry.

• The image is available but with a different tag. This is treated the same way as if the image was not available in the host machine: the correct image will be downloaded before being started.

• The image is already available. The container can be started immediately.

• Some of the layers of the image are available. This case derives from the incremental way images are built, which encourages image layer re-usability. In this case, only the missing layers (uniquely identified with a sha256 hash of their content) will be pulled from the docker registry. Once all layers are available, Docker will create the unified image of the application, and the container can be started.

The goal of this work is to better understand the different phases of the Docker container deployment process -in particular in terms of hardware resource usage -and to propose alternative techniques to speed up the download and installation of the required image layers. We assume that the image cache is empty at the time of the deployment request: fog computing servers will most likely have very limited storage capacity so in this context we expect that cache misses will be the norm rather than the exception.

Related work

Many recent research efforts have recognized the potential of single-board devices for building future fog computing infrastructures and have evaluated their suitability for handling cloud-like types of workloads. For instance, Bellavista et al studied the practicality of Docker container deployment in fog computing infrastructures for IoT applications [START_REF] Bellavista | Feasibility of fog computing deployment based on Docker containerization over RaspberryPi[END_REF]. They demonstrated that even extremely constrained devices such as Raspberry PIs may be successfully used to build IoT cloud gateways. They concluded that with proper configuration and optimization, these cost-effective devices can achieve scalable performance with minimal overhead. However, the study was carried out assuming that the Docker container images were already cached in the local nodes. In contrast, we largely focus on the download-and-install part of the Docker container deployment, and show that simple updates in the Docker implementation can significantly improve the performance of this operation.

CoMICon is a distributed Docker registry which aims to reduce the container provisioning time [START_REF] Nathan | CoMICon: A co-operative management system for docker container images[END_REF]. It distributes layers of an image among multiple nodes to increase availability. The proposed model also allows one to pull an image from multiple registries simultaneously, which reduces the average layer's download times. Similar approaches for distributed docker image downloads using various peer-to-peer protocols [START_REF] Babrou | Docker registry bay[END_REF][START_REF] Ma | Dockyard -container and artifact repository[END_REF]. However, distributed downloading solutions rely on the assumption that several powerful servers are interconnected with a high-speed local-area network, and therefore that the main performance bottleneck is the long-distance network to a remote centralized repository. In the case of fog computing platforms, servers will be geographically distributed to maximize proximity to the end users, and they will rarely be connected using high-capacity networks. As we discuss in the next section, the main bottleneck in fog computing nodes is created by hardware limitations of every individual node.

Another way to improve the container deployment time is to propose a new Docker storage driver. Slacker proposes to rely on a centralized NFS file system to share the images between all the nodes and registries [START_REF] Harter | Slacker: Fast distribution with lazy Docker containers[END_REF]. The lazy pulling of the container image in the proposed model significantly improves the overall container deployment time. However, Slacker expects that the container image is already present in the local multi-server cluster environment; in contrast, a fog computing environment is made of large numbers of nodes located far from each other, and the limited storage capacity of each node implies that few images can be stored locally for future use. Another difference is that Slacker requires flattening the Docker images in a single layer. This makes it easier to support snapshot and clone operations, but it deviates from the standard Docker philosophy which promotes the layering system as a way to simplify image creation and updates. Slacker therefore requires the use of a modified Docker storage driver (which implements de-duplication features) while our work keeps the image structure unmodified and does not constraint the choice of a storage driver. We discuss the topic of flattening Docker images in Section 5.1.

Understanding the Docker container deployment process

To understand the Docker container deployment process in full details we analyzed the hardware resource usage during the download, installation and deployment of a number of Docker images on a Raspberry PI-based infrastructure.

The limited hardware capabilities were instrumental in highlighting the inefficiencies of this process, which would be more difficult to pinpoint using faster server machines.

Experimental setup

We monitored the Docker deployment process on a testbed which consists of three Raspberry Pi 3 machines connected to each other and to the rest of the Internet with 10 Gbps Ethernet [START_REF]The mobile edge cloud testbed at IRISA Myriads team. YouTube video[END_REF]. The testbed was installed with the latest Docker version (17.06) This setup also allowed us to emulate slower network connections -which are arguably representative of real fog computing scenarios -by throttling network traffic at the network interface level. We used the tc (Traffic Control) command to run experiments either with unlimited bandwidth, or with limits of 1 Mbps, 512 kbps or 256 kbps. Table 1 depicts the three Docker images we used for this study. The first image simply conveys a standard Ubuntu operating system: it is composed of one layer containing most of the content, and four small additional layers which contain various updates of the base layer. The second is the Mubuntu image already presented in Figure 1. Finally, as the name suggests, the BigLayers image is composed of four big layers which allow us to highlight the effect of the layering system on container deployment performance.

We instrumented the testbed nodes to monitor the overall deployment time as well as the utilization of important resources during the container deployment process:

• Deployment time: We measured the deployment time from the moment the deployment command is issued, until the time when Docker reports that the container is started.

• Network activities: Network activities include incoming data and outgoing data during deployment. We used the nethogs tool to monitor the network activities during the whole deployment processes at a 1-second granularity [START_REF] Engelen | raboof/nethogs: Linux 'net top' tool[END_REF]. The script traces the specific network activity of the Docker daemon, and therefore does not take other sources of background traffic into account.

• Disk throughput: We monitored the disk activity with the iostat Linux command which monitors the number of bytes written to or read from disk at a 1-second granularity.

• CPU usage: We monitored CPU utilization by watching the /proc/stat file at a 1-second granularity.

Unless otherwise stated, every container deployment experiment was issued on an idle node, and with an empty image cache.

Monitoring the Docker container deployment process

Figure 2 depicts the results when deploying the three images using regular Docker. Figure 2(a) shows the deployment time of our three images in different network conditions: deploying the Ubuntu, Mubuntu and Biglayers images with unlimited network bandwidth respectively takes 240, 333 and 615 seconds. Clearly, the overall container deployment time is roughly proportional to the size of the image. When throttling the network capacity, deployment times grow steadily as the network capacity is reduced to 1 Mbps, 512 kbps, and 256 kbps. For instance, deploying the Ubuntu container takes 6 minutes when the network capacity is reduced to 512 kbps. This is considerable with regards to the deployment efficiency one would expect from a container-based infrastructure. However, the interesting information for us is the reason why deployment takes so long, as we discuss next. the image layers from the remote image registry. By default Docker downloads up to three image layers in parallel. The duration of downloads clearly depend on the image size and the available network capacity: between 55 s and 200 s for the Ubuntu and Mubuntu images. During this phase, we observe no significant disk activity in the host machine, which indicates that the downloaded file is kept in main memory.

After the download phase, Docker extracts the downloaded image layers to the disk before building the final image of the application. The extraction of a layer involves two operations: decompression (which is CPU-intensive) and writing to the disk (which is disk-intensive). We observe that the resource utilization alternates between periods during which the CPU is busy (∼40% utilization) while few disk activities are performed, and periods during which disk writes are the only notable activity of the system. We conclude that, after the image layers have been downloaded, Docker sequentially decompresses the image and writes the decompressed data to disk. When the image data is big, Docker alternates between partial decompressions and disk writes, while maintaining the same sequential behavior.

We see a very similar phenomenon in Figures 2(c) and 2(d). However, in here the downloading of the first layer terminates before the other layers have finished downloading. The extraction of the first layer can therefore start before the end of the download phase, creating a small overlap between the downloading and extraction phases.

Critical observations

From the previous experiments we derive a few important observations.

Overall deployment time

The overall deployment of a new container mainly involves three operations: searching for the cached image, pulling the image from the registry and starting the container. Our work assumes that the image is not cached on the machine, so every container deployment involves pulling the image from the registry. As we have seen, Docker takes a significant amount of time for pulling the image from the registry while the other two operations take a negligible amount of time. In this paper, we therefore mainly focus on optimizing the Docker image pull operation.

Pulling image layers in parallel

By default, Docker downloads image layers in parallel with a maximum parallelism level of three. These layers are then decompressed and extracted to disk sequentially starting from the first layer. However, when the available network bandwidth is limited, downloading multiple layers in parallel will delay the download completion of the first layer, and therefore will postpone the moment when the decompression and extraction process can start. Therefore, delaying the downloading of the first layer ultimately leads to slowing down the extraction phase.

Single-threaded decompression

Docker always ships the image layers in compressed form, usually implemented as a gzipped tar file. This reduces the transmission cost of the image layers but it increases the CPU demand on the server node to decompress the images before extracting the image to disk. Docker decompresses the images via a call to the standard gunzip.go function, which happens to be single-threaded. However, even very limited machines usually have several CPU cores available (4 cores in the case of a Raspberry Pi 3). The whole process is therefore bottlenecked by the single-threaded decompression. As a result the CPU utilization never grows beyond ∼40% of the four cores of the machine, wasting precious computation resources which may be exploited to speed up image decompression.

Resource under-utilization

The standard Docker container deployment process under-utilizes the available hardware resources. Essentially, deploying a container begins with a networkintensive phase during which the CPU and disk are mostly idle. It then alternates between CPU-intensive decompression operations (during which the network and disk are mostly idle) and I/O-intensive image extraction operations (during which the network and CPU are mostly idle). The only case where these operations slightly overlap are images such as Mubuntu and BigLayers when the decompress and extraction process of the first layer can start while the last images are still being downloaded.

This resource under-utilization is one of the main reason for the poor performance of the overall container deployment process. The main contribution of this paper is to show how one may reorganize the Docker deployment process to maximize resource utilization during deployment.

Optimizing the container deployment process

To address the inefficiencies presented in the previous section we propose and evaluate three optimization techniques to speed up the container provisioning time. Each optimization addresses a different issue in the standard Docker container deployment. We can therefore combine them all together, which brings significant performance improvement.

Sequential image layer downloading

As previously discussed, Docker parallelizes image downloads from the central repository to the local node, with a default concurrency degree of 3. This is a classical technique to maximize the overall network throughput. However, in the specific case of Docker image downloads this strategy has a negative effect because the next phases of the container deployment, namely the decompress and extraction phases, must take place sequentially to preserve the Copy-on-Write policy of Docker storage drivers. The decompress & extract phase can start only after the first layer has been downloaded. Downloading multiple image layers in parallel will delay the download completion time of the first layer because this download must share network resources with other less-urgent image downloads, and will therefore also delay the moment when the first layer can start its decompress & extract phase.

The only cases where the decompression & extraction of one layer overlaps with the download of another image can seen in Figure 2(c) & 2(d). They result from the fact that the download concurrency degree delays the downloading of the last images. We therefore propose to extend this phenomenon, and to reduce the download concurrency degree to one, essentially reverting to a sequential download of the image layers one after another.

Figure 3 illustrates the effect of downloading multiple layers sequentially rather than in parallel, in an example with an image made of three layers. In Implementing sequential image downloading requires additional inter-thread synchronization: in this new model the downloading of layer n can start only after the end of the layer n -1 download, whereas the decompress & extract of layer n can start only after layer n has been downloaded and the layer n -1 has finished its extraction. A simple way to implement this is to set the "max-concurrent-downloads" parameter to 1 in the /etc/docker/daemon.json configuration file.

Figure 4 depicts the host machine's resource usage when using sequential downloading of our reference images, and compares the overall deployment times with various network bandwidth limitations. Figure 4(a) shows the resource usage when deploying the Ubuntu image with sequential downloading and a 1 Mbps network capacity. The figure is not much different from Figure 2(a) where the image downloads were done in parallel. The reason is that the Ubuntu image contains only one layer with a significant size, so the downloading and extraction of layers 2-5 is very short compared to layer 1. However, in Figures 4(b utilization of hardware resources is much greater, with in particular a clear overlap between periods of intensive network, CPU and I/O resources. Also we can observe that the decompression of the first layer (visible as the first spike of CPU utilization) takes place sooner than in Figure 2. Figure 4(d) compares the overall container deployment times with parallel and sequential downloads in various network conditions. When the network capacity is unlimited the performance gains in the deployment of the Ubuntu, Mubuntu and BigLayers images are 3%, 4.2% and 6% respectively.

However, the performance gains grow steadily as the available network bandwidth gets reduced. With a bandwidth cap of 256 kbps, sequential downloading brings improvements of 6% for the Ubuntu image, 10% for Mubuntu and 12% for BigLayers. This is due to the fact that slower network capacities exacerbate the duration of the download phases and increases the delaying effect of parallel layer downloading.

Sequential downloading therefore provides modest yet non-negligible performance gains. This technique works best when the deployed image contains multiple large layers, and when the network capacity is very limited. These conditions happen to match the properties of a container deployment in fog computing environments where non-trivial applications will be deployed in extremely distributed infrastructures which necessarily rely on limited commodity networks.

Multi-threaded layer decompression

Docker image layers are stored and downloaded in the form of a gzipped tar file.

After downloading the files from the registry, the compute node therefore needs to decompress every layer before building the image on disk. In our experiments based on Raspberry PI and an unlimited network capacity, the duration of the decompression phase is greater than that of the image download. Increasing the speed of file decompression therefore has the potential to significantly reduce the overall container deployment time. By default, Docker compresses image layers using gzip. Decompression is implemented entirely in the Go language using the standard gunzip.go library [START_REF]Source[END_REF]. However, this function is single-threaded which means that it is unable to exploit multiple cores to speed up decompression. As a result, the CPU utilization during decompression never exceeds 40% of the four available cores in the Raspberry Pi machine.

We therefore propose to replace the single-threaded gunzip.go library with a multi-threaded implementation so that all the available CPU resources may be used to speed up this part of the container deployment process. We use pgzip, which is a multi-threaded implementation of the standard gzip/gunzip functions [START_REF] Post | klauspost/pgzip: Go parallel gzip (de)compression[END_REF]. Its functionalities are exactly the same as those of the standard gzip, however it splits the work between multiple independent threads. When applied to large files of at least 1 MB, this can significantly speed up decompression.

To determine the appropriate number of threads we should allow pgzip to use, we deployed a custom container image while varying the available number of threads. We used a very simple image which consists of a single layer of 20 MB in compressed form. This allows us to better isolate the performance gains of the parallel decompression from other effects such as the possible overlap of the decompression with the download of other layers. The results are depicted in Figure 5.

When pgzip uses a single thread, the performance and CPU utilization during decompression are very similar to the standard gunzip implementation. However, when we increase the number of threads from 1 to 12, the overall container deployment time decreases from 154 s to 136 s. At the same time, the CPU utilization during decompression steadily increases from 40% to 71% of the four available CPU cores. If we push beyond 12 threads, no additional gains are observed. We clearly see that the parallel decompression does not scale linearly, as it is not able to exploit the full capacity of the overall CPU: this is due to the fact that gzip decompression must process data blocks of variable size so the decompression operation itself is inherently single-threaded [START_REF] Sitaridi | Massively-parallel lossless data decompression[END_REF]. The benefit of multi-threading decompression is that other necessary operations during decompression (essentially data buffering and CRC verification) can be delegated to other threads and moved out of the critical path.

Figure 6 shows the effect of using parallel decompression when deploying our three standard container images with 12 threads. We observe in Figures 6(a), 6(b) and 6(c) that the CPU utilization is greater during the decompression phases than with standard Docker, in the order of 70% utilization instead of 40%. Also, the decompression phase is notably shorter. The same phenomenon is visible in all three images.

We also notice that the parallel image download phase is fairly CPU-intensive: in the examples of the Mubuntu and the BigLayers images which both have several large layers to decompress, the CPU utilization during downloading grows up to 70% for Mubuntu and even 90% for BigLayers. This clearly indicates that it would be pointless to attempt parallel image layer decompression while simultaneously downloading multiple image layers.

Finally, Figure 6(d) compares the overall container deployment times with parallel decompression against that of the standard Docker. The network performance does not influence the decompression time so we conducted the evaluation only with an unlimited network capacity. The performance gain from multi-threaded decompression is similar for all three images, in the order of 17% of the overall deployment time.

The standard single-threaded gzip implementation creates an unnecessary performance bottleneck because it under-utilizes the CPU resources during the decompression of the image layer. Although parallelizing data decompression is very hard and it cannot offer linear speedup, parallel decompression allows one to move the tasks not directly related to decompression to helper threads, which still provides interesting performance benefits. Multi-threading decompression increases the CPU usage, and reduces the overall Docker container deployment times.

I/O pipelining

Despite the sequential downloading and the multi-threaded decompression techniques, the container deployment process still under-utilizes the hardware resources. The reason is due to the sequential nature of the workflow which is applied to each individual layer. Each layer is first downloaded in its entirety, then it is decompressed entirely, then it is extracted to disk. This requires Docker to keep the entire decompressed layer in memory, which can be significant considering that a Raspberry Pi 3 has only 1 GB of main memory. Also, it means that the first significant disk activity can start only after the first layer has been fully downloaded and decompressed. Similarly, Docker necessarily decompresses and extracts the last layer to disk while the networking device is mostly inactive.

However, there is no strict requirement for the download, decompress and extraction of a single layer to take place sequentially. For example, decompression may start right after the first bytes of the compressed layer have been downloaded. Similarly, extracting the layer may start immediately after the beginning of the layer image has been decompressed.

We therefore reorganize the download, decompression and extraction of a single layer in three separate threads where each thread pipelines data to the next as soon as some data is available. In Unix shell syntax this essentially replaces the sequential "download; decompress; crc-check; extract" command with the concurrent "download | decompress | crc-check | extract" command. Figure 7 illustrates this technique with four threads responsible for downloading and decompression a Docker image layer. The thread TD1 downloads the image layer while TR1 performs the decompression, TC1 calculates the CRC, and finally TW1 writes the decompressed data to the disk. Since we stream the incoming downloaded data without buffering the entire layer, the thread TW1 can start writing content to disk long before the download process has completed.

We implemented pipelining using the io.pipe() GO API, which creates a synchronized in-memory pipe between an Input(writer) and an Output(reader). However, we must be careful about synchronizing this process between multiple image layers: for example, if we created an independent pipeline for each layer separately, the result would violate the Docker policy that layers must be extracted to disk sequentially, as one layer may overwrite a file which is present in a lower layer. If we extracted multiple layers simultaneously we could end up with the wrong version of the file being given to the container. Rather than building complex synchronization mechanisms, we instead decided to rely on Docker's sequential downloading feature already discussed in Section 4.1. When a multilayer image is deployed, this imposes that layers are downloaded and extracted one after the other, while using the I/O pipelining technique within each layer.

We now evaluate the I/O pipelining technique using a single-layer image only. In the next section we combine all three optimization techniques and therefore show the combined effect of the sequential download and the I/O pipelining. A single-layered image can be created using a so-called "flatten" operation which creates a single tar file out of a deployed image. Since the flattened version contains a single copy of every file (even though it may have been overwritten multiple times by different layers), the flattened image is usually slightly smaller than the sum of all the initial layers' sizes.

Figure 8 compares the deployment of a flattened image between standard Docker and the I/O pipelining technique. We can see in Figure 8(a) that the pipelined version is roughly 50% faster than its standard counterpart. The reason can be found in Figures 8(b) and 8(c). In the standard deployment, resources are used one after the other: first network-intensive download, then CPU-intensive decompression, then finally disk-intensive image creation. In the pipelined version all operations take place simultaneously, which better utilizes the available hardware and significantly reduces the container deployment time.

Docker-pi

The three techniques presented here address different issues. Sequential downloading of the image layers speeds up the downloading of the first layer in slow network environments. Multi-threaded decompression speeds up the layer decompression by utilizing multiple CPU cores. Finally, I/O pipelining speeds up the deployment of each layer by conducting the download, decompress and extraction processes simultaneously, while avoiding having to keep large amounts of data in memory during the deployment process. We therefore propose Dockerpi, an optimized version of Docker which combines the three techniques to optimize container deployment on single-board machines such as Raspberry PIs. The implementation of Docker-pi is available online in the gitlab repository [START_REF] Ahmed | Docker-pi[END_REF].

Deployment time

Figure 9 depicts the resource usage and deployment time of our three standard images using Docker-pi. We can clearly see in Figures 9(a), 9(b) and 9(c) that the networking, CPU and disk resources are used simultaneously and have a much greater utilization than with the standard Docker implementation. In particular, the CPU and disk activities start very early after the first few bytes of data have been downloaded.

Finally, Figure 9(d) highlights significant speedups compared to vanilla Docker: with no network cap, Docker-pi is 73% faster than Docker for the Ubuntu image, 65% faster for Mubuntu and 58% faster for BigLayer. When we impose bandwidth caps the overall deployment time becomes constraint by the download times, while the decompression and extraction operations take place while the download is taking place. In such bandwidth-limited environments the deployment time therefore cannot be reduced any further other than by pre-fetching images before the container deployment command is issued.

The reason why the gains are lower for the Mubuntu and BigLayers images is that the default download concurrency degree of 3 in vanilla Docker already makes them benefit from some of the improvements that we generalized in Docker-pi. If we increase the concurrency degree of vanilla Docker to 4, the BigLayers image deploys in 644 s whereas Docker-pi needs only 207 s, which represents 68% improvement.

Memory usage

We now evaluate the memory footprint of Docker and Docker-pi during the deployment process. For simplicity, we deployed a single layer image and extracted memory usage of the node by watching /proc/meminfo file at a 1-second granularity. Figure 10 clearly shows the effect of pipelining on the memory footprint. Docker-pi starts extracting the layer to local disk immediately after the first few blocks of the layer are downloaded, therefore, memory footprint never exceeds 10 MB while deploying the image. In contrast, standard docker's memory usage is nearly 70 MB. The reason is that it keeps the complete compressed layer in memory, decompresses it entirely in memory again, before writing to disk and releasing both files from memory. The memory footprint of standard Docker may vary depending on the image size and concurrency degree of parallel download. In a memory-constrained de- vice like Raspberry PI which has only 1GB of RAM, this may create significant bottlenecks. On the other hand, Docker-pi uses less memory and has a fairly constant footprint during the image pull operation irrespective of image structure, which makes it a better choice in environments such as memory-constraint fog computing devices.

Performance interference with already-running containers

In all experiments presented so far, container deployment took place in an otherwise idle machine. However, this scenario is unlikely in a busy fog computing environment where numerous independent applications share a limited number of physical resources. We therefore now evaluate the impact that container deployment has on already-running containers in the same machine.

We use an Apache Web server container [11] as the already-running container so we can observe its performance while another container with the single-layer image is being deployed. The Apache server serves a constant request workload produced by the http load HTTP benchmarking tool [12]. We configured it to generate a constant load of 300 requests/second which fetch a single 5kB file. We monitor the Web server's network throughput using nethogs before, during and after the single-layer container is being deployed.

Figure 11 compares the upload throughput of the Web server while standard Docker or Docker-pi are deploying a new container image. We observe that in both cases the Web server performance is affected by the simultaneous container deployment taking place in the same machine. This is largely due to the fact that the web server and the container deployment processes need to compete for limited resources such as available network bandwidth. Interestingly, both versions of Docker impose a similar performance reduction to the web server during the time of container deployment. However, Docker-pi deploys the new container faster so the duration of the interference it creates is shorter than using regular Docker. The fact that Docker-pi generates high resource utilization during container deployment does not seem to affect other containers in greater proportions than regular Docker.

Discussion

Should we flatten all Docker images?

Flattening all Docker images may arguably provide performance improvement in the deployment process. Indeed, multiple image layers may contain successive versions of the same file whereas a flattened image contains only the final version of every file. A flattened image is therefore always a little smaller than its multilayered counterpart. Systems like Slacker actually rely on the fact that images have been flattened [START_REF] Harter | Slacker: Fast distribution with lazy Docker containers[END_REF]. On the other hand, Docker-pi supports both flattened images and unmodified multi-layer images. We however do not believe that flattening all images would bring significant benefits. Docker does not provide any standard tool to flatten images. This operation must be done manually by first exporting an image with all its layers, then reimporting the result as a single layer while re-introducing the startup commands from all the initial layers. The operation must be redone every time any update is made in any of the layers. Although this process could be integrated in a standard image build workflow, it contradicts the Docker philosophy which promotes incremental development based on image layer reusability.

In a system where many applications execute concurrently, one may reasonably expect many images to share at least the same base layers (e.g., Ubuntu) which produce a standard execution environment. If all images were flattened this would create large amounts of redundancy between different images, creating the need for sophisticated de-duplication techniques [START_REF] Harter | Slacker: Fast distribution with lazy Docker containers[END_REF]. On the other hand, we believe that the layering system can be seen as a domain-specific form of de-duplication which naturally integrates in a developer's devops workflow. We therefore prefer keeping docker images unmodified, and demonstrated that container deployment can be made extremely efficient without the need for flattening images.

Does Docker-pi work also for powerful server machines?

Although we designed Docker-pi for single-board machines, the inefficiencies of vanilla Docker also exist in powerful server environments. We therefore evaluate the respective performance of Docker and Docker-pi in the Grid'5000 testbed which is commonly used for research on parallel and distributed computing including Cloud, HPC and Big Data [START_REF] Balouek | Adding virtualization capabilities to the Grid'5000 testbed[END_REF]. We specifically use a Dell PowerEdge C6220 server equipped with two 10-core Intel Xeon E5-2660v2 processors running at 2.2GHz, 128 GB of main memory and two 10 Gbps network connections, and do not cap the network bandwidth. Figure 12 compares the deployment times of Docker and Docker-pi with our three standard images. Obviously container deployment is much faster in this environment than in Raspberry PIs. However, here as well Docker-pi provides respectable performance improvement in the order of 23% (Ubuntu), 29% (Mubuntu) and 36% (BigLayers). In this powerful server the network and CPU resources cannot be considered as bottlenecks so the sequential layer downloading and multi-threaded decompression techniques bring almost no improvement compared to the standard Docker. On the other hand, the sequential nature of the download/decompress/extract process is still present regardless of the hardware architecture, so the I/O pipelining technique brings similar performance gains as with the Raspberry PI.

Conclusion

The transition from virtual machine-based infrastructures to container-based ones brings the promise of swift and efficient software deployment in largescale computing infrastructures. However, this promise is not being held in fog computing platforms which are often made of very small computers such as Raspberry PIs. In such environments, deploying even a very simple Docker container may take multiple minutes.

We studied the Docker container deployment process in details and identified three sources of inefficiency: (1) Docker downloads multiple layers in parallel;

(2) it uses single-threaded decompression; and (3) it sequentially downloads, decompresses and extracts any given image layer. We proposed three optimization techniques which, once combined together, speed up container deployment roughly by a factor 4. Last but not least, we demonstrated that these optimizations also bring significant benefits in regular server environments.

This work eliminates the unnecessary delays that take place during container deployment. Depending on the hardware, deployment time is now basically dictated only by the slowest of the three main resources: network bandwidth, CPU, or disk I/O. As hardware will evolve in the next years the bottleneck may shift from one to the other. But, regardless of the specificities of any particular machine, Docker-pi will exploit the available hardware to its fullest extent.

Figure 1 :

 1 Figure 1: Structure of the "Mubuntu" container image.

Figure 2 (

 2 Figure2depicts the results when deploying the three images using regular Docker. Figure2(a) shows the deployment time of our three images in different network conditions: deploying the Ubuntu, Mubuntu and Biglayers images with unlimited network bandwidth respectively takes 240, 333 and 615 seconds. Clearly, the overall container deployment time is roughly proportional to the size of the image. When throttling the network capacity, deployment times grow steadily as the network capacity is reduced to 1 Mbps, 512 kbps, and 256 kbps. For instance, deploying the Ubuntu container takes 6 minutes when the network capacity is reduced to 512 kbps. This is considerable with regards to the deployment efficiency one would expect from a container-based infrastructure. However, the interesting information for us is the reason why deployment takes so long, as we discuss next.Figure2(b) depicts the utilization of different hardware resources from the host machine during the deployment of the standard Ubuntu image. The red line shows incoming network bandwidth utilization, while the blue curve represents the number of bytes written to the disk and the black line shows the CPU utilization. The first phase after the container creation command is issued involves intensive network activities, which indicates that Docker is downloading

Figure 2 :

 2 Figure 2: Deployment times and resource usage using standard Docker.

  (a) Standard Docker pull with parallel layer download. (b) Docker pull with sequential layer download.

Figure 3 :

 3 Figure 3: Standard and sequential layer pull operations.

  ) and 4(c), we observe that after the downloading of layer 1 has completed, the

Figure 4 :

 4 Figure 4: Resource usage and deployment time with sequential layers downloading.

Figure 5 :

 5 Figure 5: Impact of the number of pgzip threads on the deployment time.

Figure 6 :

 6 Figure 6: Resource usage and deployment time with multi-threaded image layer decompression.

Figure 7 :

 7 Figure 7: Docker pull operation with I/O pipelining.

Figure 8 :

 8 Figure 8: Deployment time and resource usage with I/O pipelining.

Figure 9 :

 9 Figure 9: Resource usage and deployment time with Docker-pi.

Figure 10 :

 10 Figure 10: Memory footprint of Docker and Docker-pi during container deployment.

Figure 11 :

 11 Figure 11: Upload throughput of the Apache web server.

Figure 12 :

 12 Figure 12: Deployment time of Docker and Docker-pi in Grid'5000.

Table 1 :

 1 Structure of the Docker images.

		Ubuntu Mubuntu Biglayers
		image	image	image
	6th layer	-	51 MB	-
	5th layer	<1 MB	<1 MB	-
	4th layer	<1 MB	<1 MB	62 MB
	3rd layer	<1 MB	<1 MB	54 MB
	2nd layer	<1 MB	<1 MB	64 MB
	1st layer	46 MB	46 MB	52 MB
	Total size	50 MB	101 MB	232 MB


Maria Atanassova

Valérie Mazan

Isabelle Billard
email: isabelle.billard@lepmi.grenoble-inp.fr

] M Atanassova

Modulating the solubilities of ionic liquid components solubilities in aqueous-ionic liquid biphasic systems: a Q-NMR investigation

Keywords: ionic liquids, biphasic systems, perchlorate ions, Q-NMR

published or not. The documents may come

Modulating ILs' components solubilities in aqueous-ionic liquid biphasic systems: a Q-NMR investigation

Introduction

The aim of green or sustainable chemistry is the development of innovative highly efficient technological processes eliminating hazardous chemicals for man and the environment. The growing awareness of safety and environmental impact related with the use of molecular diluents renders their replacement with less noxious alternatives desirable. [1,2] One of the ideas under study is the replacement of molecular diluents by ionic liquids. Ionic liquids (ILs) are organic salts with melting temperature below 100°C, due to their ions' delocalized charge and asymmetry that prevent crystallization. They are known since 1914, i.e. 100 years, when the first compound [(C 2 H 5 )NH 3 ][NO 3 ] was synthesized by Paul Walden with melting point 12 o C. ILs are a class of diluents with unusual solvating properties as compared to molecular diluents. ILs differ from the traditional eutectic molten salts (LiCl/KCl) because most of them are liquid at room temperature. The use of ILs as "environmentally friendly alternative diluents" is in accordance with some of the twelve principles of the green chemistry. [START_REF]Ionic Liquids: Theory, Properties, New Approaches[END_REF] The main reason to this can be found in the negligible flammability and volatility that most ILs display (due to their ionic character) in contrast to traditional molecular organic diluents. Thus, the risk of air pollution is minimal due to their non-volatile characteristics. These properties render them inherently safer. Furthermore, ILs are often said to be chemically and thermally stable even up to 350 o C. This implies that they are safe to work with in laboratory and they are very attractive for industrial use, too. As a consequence, in the beginning of 21 st century, ILs are one of the most interesting and rapidly developing areas of modern physical chemistry, technologies and engineering [START_REF] Wasserscheid | Ionic liquids in synthesis[END_REF][START_REF] Billard | Ionic liquids: new hopes for efficient lanthanide/actinide extraction and separation?[END_REF][START_REF] Sun | [END_REF][7][8] in view of the reduction of VOCs consumption and waste production. In particular, in the field of metal extraction/separation/recycling by liquid/liquid processes, hydrophobic ILs of the type [C n C m im][Tf 2 N] (1-alkyl, 3-alkyl-imidazolium bis(trifluoromethylsulfonyl)imide) have already proved to be tremendously efficient media for a large variety of metals, [9] from Li + to Pu 4+ , [10,11] including d-elements [1,2,[11][12][13] and lanthanoids. [14][15][16][17][18][19] The huge potential that ILs present for extraction processes is due to complex extraction mechanisms, strongly dependent not only on the nature of the IL but also on the aqueous phase composition, [20] most often based on nitric or hydrochloric acids. Based on several experimental evidences, it is now acknowledged that metal extraction in aqueous-IL systems proceeds mainly by ion exchange, either cationic or anionic, although neutral metal species were also established. [14,[21][22][23] This escape of ILs' components is a serious eco problem (not speaking of the cost drawbacks) and should be controlled limited to a minimum and avoided if possible because all ILs cannot be considered environmentally benign. [24] The "green" character of [C n C m im][Tf 2 N] is critically assessed according to EU Hazard codes (T,N) and nowadays, a wealth of experimental works have demonstrated that these ILs and many others are toxic to aquatic and human life. [25][26][27] It is wrong to assume that the risk hazards of the used precursors (labeled with symbols corrosive, harmful and toxic) will fade away after their conversion into ILs. [25] So, the possible release into the aquatic environment of either cationic or anionic IL components cannot be neglected because of their potential toxicity and limited biodegradability. [28,29] Many current studies in risk assessment of ILs cover aquatic ecotoxicity, dealing with photoplankton organisms [30,31] or fish. [32] The acute toxicity of 15 widely used ILs to fish (zebrafish, Danio rerio) was evaluated by Pretti et al. [32] The authors have assessed that imidazolium, pyridinium and pyrrolidinium based IL can be regarded as non-highly lethal towards zebrafish (LC 50 >100 mgL -1 ). Despite this rather reassuring result, enlarging the knowledge about ILs' hazard potentials to fully understand the prospective fate of ILs to man requests state-of-the art studies of broad concern. This includes works on enzymes, mammalian cells, [33] leukemia, glioma and rat cells [34] as well as investigations of the mutagenicity of ILs. [35] Most tests have indicated that IL toxicity increases with increasing the alkyl chain substituent length. [34] The anion can also contribute to toxicity, but in most cases anion effects are less drastic compared to the side chain effect 17 and the role of anion type remains uncertain. [25] As a consequence, although ILs have been widely accepted as "greener" diluents, all processes, and in particular, liquid/liquid extraction of metals, in which the gradual dissolution of cationic and anionic constituents of IL into the aqueous phase occurs must be characterized and controlled. Obviously, ionic exchange is unavoidable in aqueous/IL biphasic systems because owing to the polarity of water and the presence of ions as IL components, there will always be interactions between ions from the two phases, as mixing offers a better energy balance. [20] Some authors have thus questioned the greenness of ILs. [36] Clearly, the knowledge of the mutual solubilities of water and ILs is important as regards their applications as liquid media in the chemical engineering field. To understand and master the behavior of IL-based extraction systems it is helpful to begin by considering analogous systems in the absence of a metal ion as well as an extractant. Such studies are of interest to the field of metallic extraction but also on a wider perspective, in order to predict their eco impact and to overcome their leaching drawback by adjusting their chemical composition. [29] The purpose of the present work is thus to study the influence of three strong monobasic acids often used in liquid/liquid extraction of metallic ions [37] (HClO 4 , pK a = -10; HCl, pK a ≈ -3; HNO 3 , pK a ˂ -1) and of their corresponding sodium salts onto the loss of IL components to aqueous phases. For this reason, the efforts to examine chloride, nitrate and perchlorate-based aqueous phases in contact with ILs ([C 1 C n im][Tf 2 N], n = 2, 4, 6, 8 and 10) began with the determination of the concentrations of various entities (D + , D 2 O -as NMR surrogates of H + and H 2 O-, Tf 2 N -, C 1 C n im + ) in the lower and upper phases. Other experiments were focused on the effect of ionic strength (0.1 M for NaCl and NaNO 3 , and 0.1 M, 0.2 M, 0.4 M for NaClO 4 ) on the solubilities. The obtained results give some insights into the fundamental aspects of the behavior of ILs, as a practical value in efforts to employing these unique diluents as innovative organic phases for metal ion extraction and separation and other applications.

Experimental Section

Reagents: The ILs 1-ethyl-, 1-butyl-, 1-hexyl-, 1-octyl-and 1-decyl-3-methyl-imidazoliumbis(trifluoromethanesulfonyl)imide, (purity, 99.5%) were purchased from Solvionic (Toulouse, France). ILs unavoidably absorb H 2 O from the atmosphere and their average water content is ca. 200 ppm as purchased. Thus, ILs were dried under vacuum following a previously published procedure [38] prior to sample preparation. Due to their hydrophobicity, they can be dried to very low final water contents (20 ppm) prior to mixing. All aqueous solutions have been prepared with deuterated water (99.9 atom % D, Aldrich). The mineral acids are DCl (35%), DNO 3 (65%) and DClO 4 (68%) (in D 2 O, 99 atom % D, Aldrich). The internal standard used in 1 H NMR is trisodium citrate dehydrate (Sigma-Aldrich, 99%) chosen because its protons are well separated from those of the studied IL's cations. The standard used in 19 F NMR is sodium trifluoroacetate (Alfa Aesar, 98%). 1-methyl-3-octylimidazolium chloride is with purity > 97% (Aldrich) for T1 measurements. All deuterated solutions were stored under nitrogen in order to avoid hydrogen exchange with the atmosphere. [39] All other reagents purchased from Merck used in this study were of analytical grade and were used without any further purification. Apparatus: Mechanical shaker model IKA Vibrax VXR was used as well as centrifuge Micro Star 12 for contacting/separating phases. The D 2 O amount in the IL phases was titrated by the Karl Fischer method with a coulometer (Mettler Toledo DL 32). The uncertainty is equal to 5%. Owing to the redox reaction at the basis of the Karl-Fischer titration, the water content of samples containing ClO 4 -anions cannot be reliably measured and is thus not presented. As a precaution, Karl-Fischer data for samples containing nitrate ions are also not displayed. The pD values of the deuterated aqueous solutions (before and after contact with the IL phases, n = 4, 6, 8, 10) were measured by Schott titrator (Titroline Easy). The uncertainty is equal to 0.5%. For these two methods no particular caution was set concerning the use of D 2 O/D + instead of H 2 O/H + . All NMR spectra were recorded on a Bruker Avance 300 MHz (Probe head: P BBO 300S1 BBF-H-D-05Z).

Aqueous-ionic liquid biphasic systems: In this paper, the term "aqueous" refers only to D 2 O and "aqueous phase composition" refers to composition prior to equilibration with the IL phase. All systems studied are biphasic under ambient temperature conditions once aqueous and IL phases are contacted and neither third phase formation nor phase inversion could be observed for any of the systems. Therefore, in order to designate the two phases, we will refer to the lower and upper phase, the latter being a D 2 O-rich phase (in mole fraction). Subscripts "u" and "ℓ" will designate such phases. Equal volumes (0.8 ml) of aqueous phase (containing or not 0.1 M NaCl or NaNO 3 , 0.1, 0.2 or 0.4 M of NaClO 4 and adjusted to the initial desired pD in with DCl, DNO 3 and DClO 4 accordingly) and organic phase (different ILs) were equilibrated for 2 hours (1500 rpm) at (22 ± 2) o C by mechanical shaking. After centrifugation (2 minutes, 5000 rpm) and phase separation the pD of the upper phase was measured and taken as equilibrium value, pD eq . Conversely, the D 2 O amount was measured in the lower phase. Protocol for NMR measurements: An experimental protocol using quantitative NMR for the determination of IL's cations and anions solubilized in the upper phases was recently developed by Mazan et al. [20] and was applied in the present study. Detection limits for [Tf 2 N -] and [C 1 C n im + ] are in the range of 1-2 mM. Experimental uncertainties are equal to 10% for [C 1 C n im + ] and to 5% for [Tf 2 N -].

Results and Discussion

D + extraction to the [C 1 C n im][Tf 2 N] ILs

The solubility of [D + ], in the presence or absence of the corresponding salt, in [C 1 C n im][Tf 2 N] was determined as a function of pD in . The results are presented in Figure 1 for

[C 1 C 10 im][Tf 2 N], in Fig. 2 for [C 1 C 4 im][Tf 2 N] and in Figures S1-S2 for n = 8 and 6. Using [C 1 C 10 im][Tf 2 N] and [C 1 C 8 im][Tf 2 N]
no deviation from the y = x line (i.e. pD in = pD eq , dotted line in the figures) can be observed up to pD in = 6, although a slight deviation could be seen for n = 10 above pD init = 6 and no effect of composition of the aqueous phase is seen. By comparison to a limited data set recently obtained by us for non-deuterated systems and in the absence of perchlorate salts, [40] no significant isotopic effect could be detected between pH eq and pD eq variations for Sigmoid curves of this kind were also obtained in our previous work dealing with nondeuterated and non-perchlorated samples [40] and were fitted by a purely empirical expression. Such calculated variations are shown in Fig. 2 as a dashed line. The very good agreement between the calculated and experimental variation shows that isotopic effect is very limited. Fig. 2 also illustrates a significant difference between samples containing large (i.e. > 0.1 M) amounts of sodium perchlorate and all other aqueous phase compositions.

To the best of our knowledge, such pD eq vs pD in results are unprecedented in the literature, as only very limited data have been published in this pH/pD range. For example, it has been found by titration that 79 % of the total amount of the nitric acid (pH = 2) is transferred to [(CH 3 ) 3 N(CH 2 CH 2 OMe)][Tf 2 N], but this was obtained in the presence of ca. 10 -2 M of uranyl nitrate, a situation very different from ours. [41] Although the authors do not comment on this aspect, we hypothesize that this is due, apart from the difference in ILs used which certainly has an impact onto nitric acid solubility, to the rather large uranium amount (more or less equal to the H + amount) which would allow for some U(VI) hydrolysis and/or precipitation. pD eq pD in phase onto D 2 O transfer to the IL was observed in the pD range investigated for a given IL but the decrease in water solubilisation is clearly seen as a function of n (approximately more than -60% in D 2 O solubility changing C 1 C 2 im + with C 1 C 10 im + , Fig. 4). This is ascribable to the increase in hydrophobicity of the IL phase by changing the cation, keeping the same anion: The obtained average values are in very good agreement with our recent investigation using non deteurated water. [40] Our present data fit well also with the data published by the group of Coutinho [29] when ultra-pure water was used at 25 o C: [C 1 C 6 im + ]: 10540 ppm; [C 1 C 8 im + ]: 8700 ppm, while they differ slightly for [C 1 C 4 im + ]: 14600 ppm. This may be due to the longer mixing time of 48h used by the Portuguese group, assuring the complete saturation of this rather hydrophilic IL phase. [29]

Water dragging to the IL phase

C 1 C 2 im + > C 1 C 4 im + > C 1 C 6 im + > C 1 C 8 im + > C 1 C 10 im +

3.3.Concentration of IL's anions and cations in the upper phase

Conversely, the quantities (mM) of the IL's entities transferred from the lower to the upper phase were measured by inspection of the 1 H and 19 F NMR spectra, (NMR raw data in Figures S8-S15) and plotted against the values of pD at equilibrium. It is important to recall that ion distributions between the two phases can lead to non-identical amounts of [C 1 C n im + ] and [Tf 2 N -] in the upper phase, because charge balance can be achieved by joint solubilisation or transfer of D + , Na + and/or NO 3 -, Cl -or ClO 4 -, accordingly. For one given IL, Tf 2 N -solubility in the upper phase is strongly dependent on the aqueous phase composition, but does not vary significantly as a function of pD eq as illustrated in Fig. 5 for [C 1 C 4 im][Tf 2 N] (S4 -S7: n = 2, 6, 8, 10, respectively). Consequently, all values discussed below are averaged on all pD eq values. Using [C 1 C 4 im][Tf 2 N], samples without sodium perchlorate display similar ionic solubilities at ca. 17 mM, a value in agreement with our previously published data for the same IL phase: ca. 15 mM in pure H 2 O. [20] Our value (corresponding to 0.7 wt% of C 1 C 4 im + in H 2 O) is also in fair agreement with the C 1 C 4 im + data of Freire and co-workers, [42] equal to 20 mM (average of values at 0.1 M, 0.2 M and 0.5 M of added NaCl salt, no pH control) or 19 mM (average of values at 0.1 M, 0.2 M and 0.5 M of added NaNO 3 salt, no pH control). Addition of sodium perchlorate induces a large increase in Tf 2 N -solubility, which rises to 31 mM, 40 mM and 52 mM for 0.1 M, 0.2 M and 0.4 M of NaClO 4 added, respectively. Assuming no change in equilibrium volume of the aqueous phase, this corresponds to ca 1.5 % of the total Tf 2 N -amount which is lost to the aqueous phase at maximum. This effect of sodium perchlorate addition is also observed for n = 2, n = 6 and n = 8, but it stabilizes at ≈ 20 mM for n = 10. On another hand, for a given aqueous phase composition, Tf 2 N -solubility in the upper phase decreases as n increases. Note that already with n = 6, Tf 2 N -solubility values for the samples without sodium perchlorate are very close to the detection limit, with an average value at ca. 5 mM and are below the detection limit for n = 8 and 10. Similarly, samples with sodium perchlorate display Tf 2 N - solubilities in the upper phase below the detection limit for n = 8 and 10. These values are thus not displayed in the corresponding figures. For a better understanding of this phenomenon, this double tendency is illustrated in Fig. 6 (data plotted as a function of added sodium perchlorate) and Fig. 7 (data plotted as a function of n). All data are collected in Table 1. The obtained values are in good agreement with previous published data: ca. 5 mM for [C 1 C 6 im + ][Tf 2 N -] contacted with pure H 2 O [43] or 16 mM using [C 1 C 4 im][Tf 2 N] in contact with pure 2 O at 20 o C [44] or 16.5 mM at 25 o C. [45] Figure 8. [C 1 C 6 im + ] u vs. pD eq of the aqueous phases using [C 1 C 6 im][Tf 2 N] as organic medium. Symbols as in Fig. 1. Dashed lines: averages at 6mM and 2 mM.

Discussion

In the range of chemical conditions of this work, our data show that the amount of water solubilized in the lower phase neither depends on pD in , nor on aqueous phase composition. In particular, although NaCl has some well-acknowledged salting-out effect, addition up to 0.1 M has no significant impact onto water dragging, while changes in water solubility is observed for higher concentrations. [42] More precisely, Previous experimental results by Freire and co-workers on water solubilities in [C 1 C 4 im][Tf 2 N] upon various chemical conditions (several salts, several concentrations, pH as obtained under ambient air and pressure) showed no significant effect of either NaCl or NaNO 3 up to at least 0.5 M, [42] in agreement with our data. The amount of water solely depends on the length of the alkyl chain on the imidazolium cation and the trend is in line with the increasing hydrophobicity of the successive ILs composed of C 1 C n im + and Tf 2 N -.

Second, it is important to note that the changes in pD values, as illustrated in Fig. 2 concerns rather small D + quantities: changes above pD in = 2 mean that the involved D + amounts are below ca. 5x10 -3 M. This value has to be compared to the larger amounts of sodium salts we used, in the range of 0.1 -0.4 M (one to two orders of magnitude above the D + values). Furthermore, the D + values of concern in this work are within or below the experimental uncertainties on C 1 C n im + and Tf 2 N -: therefore, it is not possible, for the data of this work to determine which species compensate for the D + depletion in the upper phase. Let us now consider the [Tf 2 N -] u and [C 1 C n im + ] u data in the absence of sodium perchlorate. As is evident from Table 1, the equilibrium values of Tf 2 N -and C 1 C n im + match perfectly, within experimental uncertainties. Therefore, although no attempts were made to determine the equilibrium values of the acid/sodium counter-anion (Cl -or NO 3 -), we can reasonably assume that the transfer of D + , as observed in Fig. 2, is compensated by the joint transfer of either NO 3 -or Cl -. It should be recalled, nevertheless, that such low amounts will be very difficult to detect by any analytical means.

The situation is markedly different in the presence of increasing amounts of sodium perchlorate. It is obvious from Table 1 that the changes in Tf 2 N -are no longer compensated by changes in C 1 C n im + concentrations. Differences in aqueous solubilities of ILs' components have already been observed by other authors. For example, C 1 C 4 im + and Cl -do not solubilize equally in an aqueous phase containing potassium phosphate. [46] In another paper, tributylammonium and bromide are shown not to dissolve similarly in an aqueous phase containing ammonium sulphate. [47] To our opinion, such data are quite scarce in the literature for two main reasons. First, precise and efficient analytical methods are requested, owing to the complexity of the aqueous phases to be scrutinized. Second, and most importantly, many authors a priori assume an identical solubility of both ILs' components and consequently only measure one of the two ions. This is typically exemplified in the work of Freire and coworkers, [42] in which the authors state that "no speculations about possible ion-exchange mechanisms will be carried". Under such a paradigm, it is clearly useless to measure both the cation and the anion solubilities. We are therefore in perfect agreement with the following comment of Freire et al., pointing that "a complete understanding of the ions partitioning process in those systems is of major importance". [42] Only a limited comparison between Freire's data and ours can be made, because common salts between the two studies are restricted to NaCl and NaNO 3 , while [C 1 C 4 im][Tf 2 N] is the only IL they investigated. On another hand, the salt concentration range they used is wider. Despite this limited experimental overlap one of the most important conclusions of Freire's work perfectly matches our results: C 1 C 4 im + solubility in the aqueous phase is strongly dependent on the nature and concentration of the salt present in the aqueous phase. More precisely, these authors observed that keeping the same cation (e.g. Na + ), different anions (Cl -, SO 4 2-, PO 4 3-etc.) induce different C 1 C 4 im + solubilities and, conversely, keeping the same anion (e. g. Cl -), different cations (Na + , Li + , K + etc.) lead to different C 1 C 4 im + solubilities as well. Interestingly enough, the authors indicate that NaCl has only "marginal effects" on the solubility of C 1 C 4 im + . Whether this insignificant effect is due to compensations between salting-in and salting-out impact of Na + and Cl -respectively (or viceversa) or simply to no effect at all of both ions remains unresolved. Despite this pending question, their general conclusion on specific impact of salt cations and anions, and of limited effect of NaCl as such, are in perfect agreement with our data. This specific effect can be modulated by changing salt concentrations. From our experimental investigation, we confirm and extend this point for perchlorate addition, which was not studied in the paper by Freire and co-workers. [42] Finally, Freire's data show that NaNO 3 addition does not strongly impact C 1 C 4 im + solubility up to 0.5 M, in accord with our limited study up to 0.1 M.

On this basis, we note that if both anions and cations have rather different effects onto C 1 C 4 im + solubilities, it would thus be rather logical that, conversely (in other words, viceversa), C 1 C 4 im + and Tf 2 N -would have specific effects onto any other salt component solubilities. This reasoning leads to possible differences between C 1 C 4 im + and Tf 2 N - solubilities in our mixtures and, by extension, between C 1 C n im + , Tf 2 N -and all other ions present in the mixtures. Differences between C 1 C 4 im + and Tf 2 N -solubilities are actually what we observe. We would thus postulate that solubility differences are a general rule in these complex salt mixtures. In this frame, the low impact of NaCl would appear an exception rather than a common feature.

Turning back to our data, in the upper phase, charge balance should be written as:

[D + ] u + [C 1 C n im + ] u + [Na + ] u = [OD -] u + [Tf 2 N -] u + [ClO 4 - ] u (eq. 1)
Where all concentrations are equilibrium ones. As already emphasized, the amount of OD - can be safely neglected in all samples. Let us consider the case of [NaClO 4 ] in = 0.4 M: it is clear that the observed difference between [Tf 2 N -] u and [C 1 C 4 im + ] u , which amounts to 42 mM (Table 1, n = 4 and 2) and indicates a depletion in positively charged species, cannot be compensated by D + transfers, for three main reasons: i) the total amount of D + in the system is significantly below the missing amount ii) data in Fig. 2 are indicative of a transfer from the upper to the lower phase, thus worsening the depletion in positively charged species in the upper phase and iii) pD in has no significant influence on Tf -, the free hydrogenation energy of the acids decreases (ΔG) which facilitates the transition into the organic phase, while protonation of [Tf 2 N -] in the aqueous phase is not a major reaction as already noted by Jensen et al. because of its low pK a , 1.2. [23] This in turn causes the change of anion of the IL salt to a rather limited extent. This does not hampers the possibility that equal amounts of Na + and ClO 4 -ions transfer together to the lower phase, in addition to the specific exchange between Tf 2 N -and ClO 4 -. As already anticipated by others, [48] our data, evidencing an intricate interplay between mutual solubilities of all ions present demonstrate that biphasic systems of this kind have more profound connections with aqueous biphasic systems than could be thought at first glance.

The fact that the effects observed here are due to ClO 4 -rather than to Na + could also be deduced from the comparison with the DCl + NaCl data, for instance. Experimental results by Gaillard et al. [49] have already evidenced that aqueous solutions containing large amounts (in the molar range, from 0.5 M to 6 M) of perchloric acid, when contacted with [C 1 C 4 im][Tf 2 N] behave somewhat differently from others, containing nitric, hydrochloric and perrhenic acids.

Attempts to understand, at a molecular/ionic level, the solvation of the two components of [C 1 C 4 im][Tf 2 N] in aqueous solutions containing sodium perchlorate and sodium chloride have been performed by use of molecular dynamics (DM). [50] However, comparisons between our experimental data and these DM results should be made with caution for the following reasons: i) These calculations have been performed for an IL concentration of 0.1 M and salt concentrations in the range 0.2 M -2 M. These concentrations values are more or less out of the range of chemical conditions we investigated. ii) Calculations have been performed for an identical number of C 1 C 4 im + and Tf 2 N -ions in water, which is very different from our case. On the one hand, DM results evidence a marked difference between Cl -and ClO 4 -in terms of organization of the salt ions around the IL cation and anion, which is in line with our data evidencing differences between these two salts in terms of individual solubilities of C 1 C n im + and Tf 2 N -. On the other hand, it is important to stress that the DM results are obtained for rather large salt concentrations, indeed favoring salt association (e.g. ClO 4

-and C 1 C 4 im + ). The authors thus conclude on a direct binding of ClO 4 and C 1 C 4 im + as being the major reason for salting-in effects that remain to be experimentally observed. Under our chemical conditions, binding is unlikely to occur and we do not observe salting-in effect of ClO 4 -. To our opinion, understanding of the fundamental reasons of the variations we observed is out of the scope of this experimental work and we will therefore limit ourselves to some general considerations. Our data demonstrate that the notion of IL solubility, for which IL would be considered as a unique entity, is incorrect. One should rather take into account individual ionic solubilities in such complex mixtures composed of water, salts, acids and ILs. Using equilibrium formalism (that may not be fully appropriate anyhow), this should be accounted for as:

H + u + Na + u + ClO 4 - u + C 1 C n im + u + Tf 2 N - u  H + ℓ + Na + ℓ + ClO 4 - ℓ + C 1 C n im + ℓ + Tf 2 N - ℓ
From this equation, it is clear that any attempt to describe our results on the basis of solubility products is most probably doomed to failure. We now turn to the possible consequences our findings have onto the efficiency of the extraction process of metallic ions by ILs of the type studied. First, it is well-known that large amounts of water dissolving in IL (i.e. the lower phase, in our experiments) modify the density and viscosity of that phase which presumably plays a key role in assisted ion extraction [51,52] but this is not the only effect to be accounted for. Many experimental studies [START_REF] Billard | Ionic liquids: new hopes for efficient lanthanide/actinide extraction and separation?[END_REF][53][54][55][56] ]. [48] In this case, the extraction of anionic complexes is possible by the transfer of the [Tf 2 N -] anions into the aqueous phase as:

Ln 3+ aq + 4HTTA IL + [C 1 C 4 im + ][Tf 2 N -] IL  [C 1 C 4 im + ][Ln(TTA) 4 ] IL + 4H + aq + [Tf 2 N -] IL (
II) Such cationic (anionic) mechanisms have been demonstrated through the addition of the IL cation (anion) as its chloride salt (lithium salt) to the upper phase, [57][58][59] which induces a decrease in the distribution ratio, as described through eq (I) (eq. II, respectively). More recently, another way to modify the equilibrium amounts of the IL cation (anion) has been evidenced: addition of large amounts of the IL anion, as its lithium salt, leads to a drop in IL's cation, as a consequence of solubility products. [20] Conversely, adding chloride salts of the IL's cation decreases the equilibrium amount of the IL's anion in the upper phase. Such external changes in either the IL's cation or anion have obvious consequences in terms of distribution ratio, according to eqs. I or II, as calculated [20] and as experimentally observed for Ln and other metallic ions. [60,61] Our data evidence a third way to play on the distribution ratio values: adding sodium perchlorate salt does change the equilibrium values of either C 1 C n im + or Tf 2 N -: By doing so, we expect increase in D ratio provided the extraction mechanism is ruled by eq. I and we predict a decrease in D for anionic exchange (eq. II). Moreover, based on this observation, we expect great differences in D values by simply replacing nitric acid by perchloric acid in liquid/liquid extraction of metallic ions towards IL phases, all other chemical aspects being equal. Similarly, caution should be paid to experimental results arising from samples containing large amounts of perchloric acid/perchlorate salts. [48] Specific studies on these two aspects are currently under progress.

Conclusions

There are several reports in literature describing the mutual solubilities of water and ILs [20,29] but to the best of our knowledge, a profound and methodical Q-NMR study was missing. We have thus performed a detailed Q-NMR study aiming at the determination of the quantity of both IL cations and anions transferred in the upper phase of biphasic systems based on aqueous solutions and ionic liquids because mutual solubility data constitute a necessary step to assess and control the environmental impact of ILs in aquatic systems prior to their applications. [29] We have evidenced a very different impact on mutual solubilities (D + , C 1 C n im + and Tf 2 N -) of perchlorate ions as compared to nitrate and chloride already at 0.1 M NaClO 4 vs NaCl or NaNO 3 . The results of the present work have important consequences on several aspects in fundamental, analytical, applied and environmental chemistry.

First, when determining the composition of aqueous biphasic systems based on ILs, caution should be paid to charge balance, as evidenced in our work: it is not enough to measure the distribution of one of the IL's component between the upper and lower phase to be assured of the distribution of the IL's counter-anion and this precautionary principle should also apply to any of the constituents of such mixtures.

Second, on a practical/industrial viewpoint, do intricate solubilisation phenomena, as evidenced in our work, totally hamper the application of ILs for liquid-liquid extraction processes? Obviously, the answer can only be derived from a minute balance between all aspects: ILs are known to tremendously increase extraction efficiencies, which represents a clear benefit, not only in terms of money but also in terms of ecological efficiency. Although liable to leakeage in aqueous phases, which is an obvious disadvantage in terms of profits, not all ILs are highly toxic and a common scale able to account for all these very different pros and cons is the basis on which an answer could be given. This is clearly out of the scope of the present work. We will limit ourselves to note that ILs appear in an increasing number of studies suggesting separation processes based on ILs for precious metals, such as radioactive ones [62] or those from the platinoïd group. [63][64][START_REF] Papaiconomou | RSC Adavances[END_REF] This is a strong indication that ILs have at minimum, a niche to occupy in liquid/liquid extraction of metals.

Finally, on an environmental perspective, it is thus not enough to conclude that increasing the length of the alkyl chains of 1-alkyl-3-methylimidazolium cations, the undesirable IL's component solubilities, which have typically been found to have a pronounced impact on metal extraction efficiency, can be successfully reduced. That ILs can be rendered "greener" simply by increasing their cation hydrophobicity is not perfectly true, and the remarkable aqueous solubility of IL's anion under some of the chemical conditions of this work definitely questions the weak environmental footprint of ILs. Furthermore, considering the differences between ILs' cation and anion solubility, it is also questionable to define an IL solubility value. Thus experiments studying ILs' toxicity should clearly make a distinction between the cation and anion properties in that respect.

Graphical abstract:

Addition of sodium perchlorate enhances ILs' anion solubility, while decreasing ILs' cation solubility to an slightly acidic aqueous phase.

  [C 1 C 10 im][Tf 2 N] and [C 1 C 8 im][Tf 2 N] up to pH in /pD in = 8. The results illustrated in Figs. 1 and S2 show that no significant solubilisation of D + in the lower phase occurs in such biphasic systems.

Figure 1 .

 1 Figure 1. pD eq vs. pD in of the aqueous phases using [C 1 C 10 im][Tf 2 N] as organic medium. Dotted line: y = x. □: DNO 3 . ■: DNO 3 and NaNO 3 0.1 M. Δ: DCl; ▲: DCl and NaCl 0.1 M; ○: DClO 4 ; •: DClO 4 and NaClO 4 0.1 M; ○: DClO 4 and NaClO 4 0.2 M; ◊: DClO 4 and NaClO 4 0.4 M.

  By contrast, when [C 1 C 4 im][Tf 2 N] and [C 1 C 6 im][Tf 2 N] (Figures2 and S1, respectively) are used, a clear deviation from the line y = x is observed, as the result of the solubility of D + in the lower phase, that leads to increase of the equilibrium pD values in the upper phase. In [C 1 C 6 im][Tf 2 N], deviation from the y = x line is observed above pD in = 2 and the effect of aqueous phase composition is hardly seen. The plateau value is equal to ca. 8.

Figure 2 .

 2 Figure2. pD eq vs. pD in of the aqueous phases using [C 1 C 4 im][Tf 2 N] as organic medium. Dotted line: y = x. Dashed line: empirical function used for non-deuterated non-perchlorated samples (see text). Symbols as in Fig.1.For [C 1 C 4 im][Tf 2 N], no experimental differences can be observed between samples containing DCl, DNO 3 and DClO 4 with or without their corresponding salt at 0.1 M. By contrast, samples with sodium perchlorate concentrations equal to 0.2 M and 0.4 M deviate from the y = x line above pD in = 3.2, with a plateau at pD eq = 6.2, while all other sample compositions lead to a deviation already above pD in = 2 and a plateau value at pD eq ≈ 7.4. For DCl samples having initial pD values at 2.75 and 3.54, the measured pD values after contact with [C 1 C 4 im][Tf 2 N] were 6.96 and 7.25, respectively. Sigmoid curves of this kind were also obtained in our previous work dealing with nondeuterated and non-perchlorated samples[40] and were fitted by a purely empirical expression. Such calculated variations are shown in Fig.2as a dashed line. The very good agreement between the calculated and experimental variation shows that isotopic effect is very limited. Fig.2also illustrates a significant difference between samples containing large (i.e. > 0.1 M) amounts of sodium perchlorate and all other aqueous phase compositions. To the best of our knowledge, such pD eq vs pD in results are unprecedented in the literature, as only very limited data have been published in this pH/pD range. For example, it has been found by titration that 79 % of the total amount of the nitric acid (pH = 2) is transferred to [(CH 3 ) 3 N(CH 2 CH 2 OMe)][Tf 2 N], but this was obtained in the presence of ca. 10 -2 M of uranyl nitrate, a situation very different from ours.[41] Although the authors do not comment on this aspect, we hypothesize that this is due, apart from the difference in ILs used which certainly has an impact onto nitric acid solubility, to the rather large uranium amount (more or less equal to the H + amount) which would allow for some U(VI) hydrolysis and/or precipitation.3.2. Water dragging to the IL phaseFigure 3 displays the D 2 O amount in the lower phase as a function of pD eq values and sample composition (chloride data only, see experimental section) for [C 1 C 4 im][Tf 2 N] equilibration, as an illustration of our results. Data for the other IL phases can be found in the supplementary materials (Fig. S3) No significant effect of D + /Na + composition of the aqueous

Figure 3

 3 displays the D 2 O amount in the lower phase as a function of pD eq values and sample composition (chloride data only, see experimental section) for [C 1 C 4 im][Tf 2 N] equilibration, as an illustration of our results. Data for the other IL phases can be found in the supplementary materials (Fig.S3) No significant effect of D + /Na + composition of the aqueous

Figure 3 .

 3 Figure 3. D 2 O amount in the lower phase vs. pD eq of the aqueous phase using [C 1 C 4 im][Tf 2 N] as organic medium. Δ: DCl; ▲: DCl and NaCl 0.1 M. Dotted line: average value of all data.

Figure 4 .

 4 Figure 4. D 2 O average amount (ppm) in the lower phase vs. n (the length of the IL cation C 1 C n im + ). Solid line is a guide for the eye only.

Figure 5 .

 5 Figure 5. [Tf 2 N -] u vs. pD eq in the aqueous phases using [C 1 C 4 im][Tf 2 N] as organic medium. Symbols as in Fig. 1. Dotted lines are average of individual series (see text).

Figure 6 .

 6 Figure 6. Average values of Tf 2 N -solubility in the upper phase, as a function of added sodium perchlorate concentration for the four ILs of this work. x: n = 2; ◊: n = 4; □: n = 6; Δ: n = 8; ○: n = 10. Dotted lines are guide for the eye only.

Figure 7 :

 7 Figure 7: Average values of Tf 2 N -solubility in the upper phase, as a function of length of the alkyl chain, for the various sodium perchlorate concentrations of this work. ◊: no sodium perchlorate; □: [NaClO 4 ] added = 0.1 M; Δ: [NaClO 4 ] added = 0.2 M; ○: [NaClO 4 ] added = 0.4 M. Dotted lines are guide for the eye only.

4 - 3 -

 43 2 N -and C 1 C 4 im + equilibrium values (Figs. 5, 8 and Suppl. Mat.). Therefore, neglecting the contributions of OD -and D + in eq. 1, we derive for n = 4 or n = 2 and [NaClO 4 ] in = 0.4 M: [Na + ] u = [ClO is thus evident that anion exchange occurs between [Tf 2 N -] ℓ and [ClO 4 -] u anions during the equilibrium process. With an increase of the anions' radius in the order Cl -˂ NO

Table 1 :

 1 Values of the equilibrium concentration of Tf 2 N -and C 1 C n im + in the upper phase.

		without NaClO 4	with NaClO 4 (0.1 M/0.2 M/0.4 M)
	n [Tf 2 N -] u	[C 1 C n im + ] u	[Tf 2 N -] u	[C 1 C n im + ] u
		(mM)	(mM)	(mM)	(mM)
				58	38
	2	42	40	66	38
				76	36
				31	21
	4	17	16	40	9
				52	10
				22
	6	5	6	31	bdl
				43
				19
	8	bdl	bdl	28	bdl
				40
				19
	10	bdl	bdl	21	bdl
				20
	bdl: below detection limit. Values are averages calculated on the basis of all experimental
	samples (pD 1-8).

  have clearly demonstrated that cation exchange is quite a common extraction mechanism in ILs. Typically, extraction proceeds as: Where S is any neutral ligand (calixarene, CMPO, crown-ether etc.) Other studies have evidenced extraction mechanisms based on anionic exchanges. For example, studies of Ln 3+ extraction to [C 1 C 4 im + ][Tf 2 N -] using high HTTA concentrations (2thenoyltrifluoroacetone, an acidic extractant) revealed the existence of anionic tetrakis complexes in the IL phase as [C 1 C 4 im + ][Ln(TTA) 4

	Ln 3+	aq + S IL + 3 C 1 C 4 im +	IL ↔ [LnS] 3+	IL + 3C 1 C 4 im +	aq	(I)
				-

Acknowledgements

The authors are grateful to FP7-PEOPLE-Marie Curie Actions-IEF for the financial support of the project INNOVILLN (622906) 2014-2016. The research in this paper was supported in part by the University of Strasbourg Institute for Advanced Study (USIAS) as part of a USIAS Fellowship. The help of Dr Bruno Vincent and Dr Maurice Coppe (NMR Centre at the Chemical Faculty of the Strasbourg University) for the NMR measurements of this work is greatly acknowledged. We also thank the three-year undergraduate student Desislava Gerginova (UCTM) for assistance.

Electronic Supplementary Information (ESI) available: Chemical structures of ILs (Scheme S-1), NMR Tables (S1-S3) concerning NMR analysis. Figures S1-S2 (pD eq vs. pD in ); Figure S3: D 2 O amount absorbed by IL phase n = 6, 8 and 10; Figures S4 -S6 [Tf 2 N -] data (n= 6, 8 and 10); Fig. S7 [C 1 C n im + ] data n = 4. This material is available free of charge via the Internet at http://....;