Jiajun Cao

Matthieu Simonin

Gene Cooperman

Christine Morin

Checkpointing as a Service in Heterogeneous Cloud Environments

Keywords: Infrastructure as a Service, Fault Tolerance, Checkpointing, Application Migration, Interoperability Infrastructure as a Service, Tolérance aux pannes, Checkpointing, Migration d'application, Interopérabilité

A non-invasive, cloud-agnostic approach is demonstrated for extending existing cloud platforms to include checkpoint-restart capability. Most cloud platforms currently rely on each application to provide its own fault tolerance. A uniform mechanism within the cloud itself serves two purposes: (a) direct support for long-running jobs, which would otherwise require a custom fault-tolerant mechanism for each application; and (b) the administrative capability to manage an over-subscribed cloud by temporarily swapping out jobs when higher priority jobs arrive. An advantage of this uniform approach is that it also supports parallel and distributed computations, over both TCP and InfiniBand, thus allowing traditional HPC applications to take advantage of an existing cloud infrastructure. Additionally, an integrated health-monitoring mechanism detects when long-running jobs either fail or incur exceptionally low performance, perhaps due to resource starvation, and proactively suspends the job. The cloud-agnostic feature is demonstrated by applying the implementation to two very different cloud platforms: Snooze and OpenStack. The use of a cloud-agnostic architecture also enables, for the first time, migration of applications from one cloud platform to another.

Introduction

Cloud computing provides users with the illusion of an infinite pool of resources available over the Internet, from which they can gain on demand and through self-service the resources they need for their applications. In less than a decade numerous cloud providers have flourished, each of them operating one or several data centers in different locations. Cloud providers target transparent failure and maintenance management, with the twin goals of satisfying their customers, and providing the high resource utilization that maximizes their profit. Many failure, reconfiguration and resource management strategies rely on the ability to migrate virtual machines both between data centers and within a single data center. Customers want their applications to be executed reliably in the cloud, and they seek to escape the vendor lock-in phenomenon by taking advantage of a market of heterogeneous clouds.

We propose a novel Checkpointing as a Service approach, which enables application checkpointing and migration in heterogeneous cloud environments. Our approach is based on a noninvasive mechanism to add fault tolerance to an existing cloud platform after the fact, with little or no modification to the cloud platform itself. It achieves its cloud-agnostic property by using an external checkpointing package, independent of the target cloud platform.

Such a cloud-agnostic checkpointing service is important for at least three distinct reasons:

1. provision of fault tolerance for long-running tasks;

2. improved cloud efficiency (low-priority applications can be suspended to stable storage, and restored only when idle CPU cycles are available); and

3. migration of tasks between distinct IaaS clouds (e.g., between one operated by the Snooze system and one operated by the OpenStack system).

The proposed Cloud-Agnostic Checkpointing Service (CACS) is retro-fitted into multiple cloud platforms. This is demonstrated for two cloud platforms: Snooze and OpenStack.

A necessary component of the CACS service is a health-monitoring mechanism that not only detects when an application has "died", but generally when an application is unhealthy. Detecting the latter is non-trivial, since only the application developer knows if the termination or nonresponsiveness of one process is fatal to the overall computation. Hence, a hook is provided for each application to determine its own "health".

Our contributions are three-fold:

• We provide the first transparent checkpointing scheme for centralized, parallel and distributed computations in the Cloud.

• The transparent checkpointing scheme is cloud-agnostic. The minimal assumptions of this approach allow it to be extended to most cloud architectures.

• Migration of computations among heterogeneous clouds is provided.

The CACS checkpointing service employs the DMTCP package [START_REF] Ansel | DMTCP: Transparent checkpointing for cluster computations and the desktop[END_REF], a checkpointer for distributed multithreaded applications. This was chosen for its transparent support of distributed applications, including both TCP/IP and the InfiniBand network [START_REF] Cao | Transparent checkpoint-restart over Infini-Band[END_REF].

Moreover, we show that our approach for computation checkpointing and migration scales with application size and with the number of applications hosted in a data center.

The remainder of this paper is organized as follows. Section 2 presents further background and motivation for the approach. In Section 3 we discuss the principles that guided the design of the cloud checkpointing service. Section 4 provides an overview of the CACS service. Section 5 presents some typical scenarios, from application submission through checkpoint, recovery Inria and/or migration to a new cloud, and finally application termination. Section 6 presents our prototype implementation. In Section 7 we analyze the results from a first experimental evaluation. Section 8 describes the related work, while the conclusions are presented in Section 9.

Motivation

The cloud-agnostic checkpointing service is intended to provide a single checkpointing solution for heterogeneous computing services. This eliminates the need for each computing service to implement its own checkpointing solution. Such solutions are required not only for long-lived computations, but also for numerous other use cases.

Context: IaaS and Heterogeneity among Clouds

IaaS clouds provide resources on demand to their customers in the form of virtual machines. IaaS clouds are heterogeneous, each coming with its own marketplace of Virtual Machine Images (VMI). Customers of an IaaS cloud provider select VMIs among those offered. Different VMIs correspond to different, possibly customized, combinations of an operating system kernel, an OS distribution, and a processor architectures (32-or 64-bit). Instances are characterized by the amount and type of resources they use (e.g., number of cores, memory capacity, disk capacity).

The IaaS cloud management system manages the life cycle of a virtual machine (VM) from submission to termination. In particular, it allocates the server resources among the virtual machines and performs VM scheduling. Servers and VMs are monitored in order to determine efficient resource management strategies. In a cloud environment, a distributed application is executed using a set of interconnected virtual machines called a virtual cluster.

Different cloud environments also introduce heterogeneity among dimensions other than those described in the previous paragraph. Servers may have different hardware configurations (e.g., Intel versus AMD processors), and may run different combinations of virtual machines and hypervisors (e.g., KVM/QEMU, Xen, and Linux containers).

A sufficiently robust checkpoint-restart package, such as the DMTCP package used here, can overcome these sources of heterogeneity. As a prerequisite, an end user must design her applications for a common denominator: compiling for the intersection of Intel and AMD instruction sets, avoiding the most recent system calls in order to provide backward compatibility, programming scalability to adjust for fewer or more cores, and even compiling for a 32-bit instruction set if a combination of 32-and 64-bit CPUs is anticipated. In this way, a cloud-agnostic checkpointing service can directly migrate applications among such heterogeneous resources.

Finally, a cloud-agnostic checkpointing service must be tolerant of the different types of IaaS cloud management systems that exist today. These include OpenStack [START_REF]OpenStack project[END_REF] (widely adopted in production data centers), Nimbus [START_REF] Keahey | Science clouds: Early experiences in cloud computing for scientific applications[END_REF] (targeting scientific computing), and Eucalyptus [START_REF] Nurmi | The Eucalyptus open-source cloud-computing system[END_REF], OpenNebula [START_REF] Milojičić | Opennebula: A cloud management tool[END_REF] and Snooze [START_REF] Feller | Snooze: A scalable and autonomic virtual machine management framework for private clouds[END_REF] (originating from academia), and Amazon EC2 (the most widely used public commercial cloud). IaaS cloud systems may use different VM disk image formats (e.g. QCOW, VMDK) and provisioning methods. They may provide different APIs for storage and VM management. However, some popular interfaces (EC2 for VM management and S3 for storage for example) have become de-facto standards. Recently, there have been a number of emerging standard APIs such as DMTF CIMI [8] or OGF OCCI [START_REF]Open Cloud Computing Interface -OCCI[END_REF], which have not yet become mainstream.

Use Cases

Many motivating use cases demonstrate the need for a portable efficient cloud checkpointing service. A first use case is fault-tolerant application execution in the cloud. Long-running jobs (such as OpenMP-based or MPI-based scientific applications) should be periodically checkpointed, so that they can be restored from their last checkpoint in the event of a failure.

Ideally, it should be possible to restore an application either in the same data center or in another one from the same cloud provider to survive catastrophic failures affecting a whole data center. However, although a second data center may be available, it may be running under a different type of infrastructure. This gives rise to the second use case: migration among heterogeneous clouds.

A third use case occurs when the cloud provider needs to transparently carry out maintenance operations. Providers can stop all applications and checkpoint them or migrate them to other clusters, before taking down a cluster for maintenance.

A fourth use case occurs in the scientific world, in the framework of advanced VM scheduling algorithms. Periods of low demand may lead to potentially low utilization rates. A VM scheduler attempts to increase resource utilization. Opportunistic preemptible leases running on backfill virtual machines have been proposed for this case by Marshall et al. [START_REF] Marshall | Improving utilization of infrastructure clouds[END_REF]. Such leases give a user access to a resource at an indeterminate time for an indeterminate amount of time, but are less expensive than traditional on-demand leases. Transparent cloud-agnostic checkpointing allows any scientific application to use such a lease.

Proactive cloud migration provides a fifth use case. For a cloud provider operating multiple possibly heterogeneous data centers it is desirable to be able to migrate VMs from one cloud to another. Energy-efficient resource management policies such as follow-the-sun aimed at exploiting renewable energy sources to the extent possible and cloud bursting are two illustrating use cases [START_REF] Wood | CloudNet: Dynamic pooling of cloud resources by live WAN migration of virtual machines[END_REF] .

A sixth use case is vendor lock-in. Cloud customers currently face vendor lock-in issues in re-targeting their distributed applications from one cloud provider to another. A cloudagnostic checkpointing service would overcome heterogeneity issues and empower cloud users to take advantage of the competitive cloud computing market by outsourcing their applications to another provider.

Last but not least is the seventh use case. Migrating legacy distributed applications to the cloud remains a tedious task for users who don't have system administration skills. In the context of IaaS clouds, porting from a cluster to a virtual cluster in the cloud may require the skills of a system administrator and the domain-specific knowledge of an end-user. The portable checkpointing service proposed here is a key building block for a cloudification service, significantly reducing the burden of legacy applications users in moving their application to the cloud. In principle, a user would simply use the CACS-based cloudification service to migrate her application from her desktop or local cluster to a selected IaaS provider, since the design of the CACS service will extend to run on other resource management services, including a Linux desktop system and the resource management system (RMS) (e.g., batch system) of an HPC cluster.

There is no claim that the current CACS service will satisfy all of the above use cases. Some use cases might require specialized cloud configurations or specialized data services [START_REF] Ramakrishnan | Frieda: Flexible robust intelligent elastic data management in cloud environments[END_REF].

Design Principles of the CACS Service

To address the requirements presented in the previous section, we developed a Cloud-Agnostic Checkpointing Service. We discuss five principles that guided its design. A key design principle of the Cloud-Agnostic Checkpointing Service is that it leverages a processlevel checkpointer for checkpointing distributed applications executed in virtual machines. There are two primary reasons why a process-level checkpointer was chosen instead of using the VM snapshot mechanism offered by hypervisors. First, snapshotting a set of virtual machines is more expensive than checkpointing a set of processes. As in the latter case the operating system is not checkpointed, the checkpoint size is much smaller. While data deduplication techniques [START_REF] Wood | CloudNet: Dynamic pooling of cloud resources by live WAN migration of virtual machines[END_REF] can be used to reduce the cost of live migration, our approach has a broader applicability being hypervisor-agnostic.Second, process-level checkpointers like DMTCP manage dependencies among communicating multithreaded processes when saving a checkpoint. When checkpointing a distributed application running in multiple VMs using VM snapshots, hypervisors fail to handle the inter-process communications of distributed processes. VM snapshots have been extensively used to checkpoint an application running in a single VM, since it provides a generic checkpointing mechanism transparent to the application, which does not need to be modified. A process-level checkpointer like DMTCP is fully transparent to the application and generic, including support for checkpointing sets of communicating multithreaded processes. Moreover, in an environment of multiple heterogeneous clouds, an approach based on process-level approach to checkpointing the distributed applications of a virtual cluster provides better portability and interoperability than one based on VM snapshots. This avoids the difficulty of porting VM images and adapting to multiple IaaS cloud management APIs, when dealing with different cloud management systems.

Eliminating the Checkpoint Management Burden

Checkpointing should come as a service, implying minimal burden for users. In our approach, users request their VMs from the CACS service rather than directly from the IaaS cloud manager, and submit their application to CACS while specifying the checkpointing policy (e.g., checkpoint frequency). The CACS service obtains the VMs, installs and configures the process-level checkpointer and the application inside the VMs, and then automatically triggers checkpoints according to the user-defined policy.

Portability and Interoperability

The CACS service has been designed to execute on top of unmodified existing IaaS cloud management systems, to address a broad IaaS cloud market. Thus, it relies on the de facto standard APIs offered by most IaaS clouds systems, namely EC2 for VM and S3 for storage management.

An important requirement is to be able to detect failures at the level of the server, the VM and the application, within the underlying IaaS cloud management system. For instance, OpenStack does not provide an API to report infrastructure failures to clients. So the CACS service must include a cloud-agnostic monitoring system. Yet at the same time, the CACS service should be able to exploit any existing monitoring mechanisms of the underlying IaaS cloud where they exist, as in the case of the Snooze VM management system.

Another portability issue arises from the fact that different IaaS management systems may use different VMI formats and offer different types of VM. This further motivated the first design decision: to use application level checkpointing rather than VM snapshots.

Scalability

The CACS service should scale with the number of concurrent VMs so that it can be used to tolerate failures in data centers; and it should scale with the size of the applications (with the number of VMs per application) so as to have a limited impact on the execution time of large distributed applications.

The choice of implementation for stable storage has an important impact on these two types of scalability. Thus, the CACS service relies on distributed parallel file systems such as Ceph [START_REF] Weil | Ceph: A scalable, high-performance distributed file system[END_REF] in order to cope with the huge volume of data to be stored when several checkpoints are taken simultaneously. Similarly, efficient VM management is also essential to limit as much as possible the recovery time.

Usability

Nowadays, providing a REST API to a service is a key feature. Resources are served using various server representations. This eases the interaction with users and with third-party software (e.g., CLI, web-based GUI). Moreover, the statelessness of server requests in a REST API provides server scalability, since communication between clients and server is loosely coupled.

Overview of the CACS Service

Next, the CACS architecture and its core components are presented. First, the underlying technology, DMTCP, is introduced. Then the CACS internal components are examined.

DMTCP Application Checkpointer

The choice of DMTCP (Distributed MultiThreaded CheckPointing) [START_REF] Ansel | DMTCP: Transparent checkpointing for cluster computations and the desktop[END_REF] for checkpoint-restart was dictated by the maturity of that ten-year old project [START_REF] Cooperman | Adaptive checkpointing for master-worker style parallelism (extended abstract)[END_REF] available as binary packages for Debian/Ubuntu, Fedora/CentOS/Scientific Linux/Red Hat, and OpenSUSE). In particular, DMTCP supports the types of migration of processes among heterogeneous environments that was described in Section 2.

In DMTCP, each application is associated with a unique DMTCP application coordinator in charge of coordinating the checkpointing of processes running on distinct computer nodes. The coordinator need not reside on a host hosting application processes and communicates with DMTCP daemons running on each node hosting application processes. When an application is restarted, a new DMTCP coordinator is used, thus avoiding any single point of failure.

Architecture of the CACS

Figure 1 depicts the overall architecture of the service. The RESTful API allows users to manage their applications and their corresponding checkpoints. The Coordinators database stores all the applications information. The Application Manager orchestrates application management (start and restart) and enforces failure recovery mechanisms. It communicates with the Cloud Manager to manage (create, destroy) virtual clusters. The Cloud Manager interacts with the underlying IaaS cloud system to manage the VMs. The Provision Manager takes the burden to efficiently configure the virtual clusters. The Checkpoint Manager component is for managing the application checkpoint images. The Monitoring Manager component enables VM and application process failure detection. It is notified about application health issues and VM failures by monitoring daemons running in each VM of the virtual cluster executing the application. In the Inria event of a notification, it interacts with the Application Manager in order to stop and/or recover the application from a previous checkpoint. An application is executed under the control of DMTCP whose daemons run in each VM hosting the application processes, with one of them running the DMTCP coordinator.

Virtual Cluster

Typical Scenarios

We describe five scenarios of a typical CACS user, ordered according to the life cycle of an application comprising of n processes run in n different VMs. The section describes in greater details some mechanisms used to handle user requests. Table 1 depicts the description of the resources managed by the API and the available operations.

Application Submission

We present application submission to the CACS service. A POST request is issued to the coordinators resource and the body contains the representation of an Application Submission Request (ASR). ASR encapsulates the virtual machine templates and the configuration parameters of DMTCP needed to start the application. Once the Application Manager validates the ASR, the application enters the CREATING phase (see Figure 2) during which virtual resources are claimed to the Cloud Manager. Once the VMs have been given to the computation, the PROVISION phase starts. In this phase, the Provision Manager remotely executes specific commands to prepare the computation to be run. The provision includes internal actions (e.g creation of checkpoint directory in the virtual machines) but also user-defined configuration (e.g. periodicity of the checkpoints, specific initializations). The provisioning phase may differ according to the storage back-end used.

The READY state is introduced to reflect the fact that all the VMs are ready to start the computation. The RUNNING state indicates that the computation is in progress. In this phase, checkpoints can be saved.

An alternative way of starting an application is given in section 5.3.

Saving Checkpoints

Three modes of transparent checkpointing are supported: (1) user-initiated checkpointing; (2) periodic checkpointing; and (3) application-initiated checkpointing (for example, at the end of each application iteration). The first case can be fulfilled by issuing a POST request to the corresponding checkpoints resource. In the second and third case, DMTCP triggers the checkpoint without the need for a POST request. CACS distinguishes between local and remote storage.

Where fast local storage is available (e.g., a local disk, an SSD, or a RAM disk inside RAM itself), the checkpoint image is written first to the local storage, and copied later to remote storage (such as Ceph and NFS) on a lazy basis.

Application Recovery, Cloning and Migration

The API enables the following scenarios : (1) application restarting (the application state is reset to a previous checkpointed state and restarted); (2) application cloning (a new application is created and restarted from a previous checkpointed state of the original application); and

Inria

(3) application migration (an application is cloned to another cloud and terminated on the source cloud).

In the first case, checkpoints metadata are retrieved from the Checkpoint Manager. Then the Application Manager triggers a passive recovery mechanism: new VMs can be restarted and provisioned if some VMs of the original set are not reachable anymore. Finally each VM in the computation downloads its corresponding checkpoint images from the storage. The process of restarting the application is delegated to DMTCP.

Cloning and migrating provide alternative ways of creating an application. In these cases, a new application is created by issuing a POST request to the coordinators resource. Second, n POST requests are sent to the corresponding checkpoints resource to upload a set of checkpoint images. Ultimately, a POST to the checkpoint resource will restart the application. This will trigger the passive recovery mechanism to generate a new virtual cluster where the application will run.

Application Termination

Terminating an application consists in removing all references of the application in the system. This can be decomposed as: (1) the deletion of the corresponding entry in the coordinator database; (2) the removal of all the stored checkpoint image from the storage; and (3) the release of the allocated virtual machines back to the pool of idle VMs in the underlying infrastructure.

The TERMINATING state is reached when an end user issues a DELETE request to the coordinator resource or when the ERROR state is set for the application. The section describes in details technical aspects of the CACS service.

Cloud Manager

The current CACS prototype supports two underlying IaaS technologies (Snooze and EC2 compatible VM management systems) allowing us to demonstrate the portability and interoperability of the CACS service in heterogeneous cloud environments. Snooze [START_REF] Feller | Snooze: A scalable and autonomic virtual machine management framework for private clouds[END_REF] is a scalable highly available system. It has been primarily designed as a small system easing the deployment of VMs and the experimentation of VM management strategies. The Cloud Manager uses the specific REST API of Snooze to manage virtual clusters. Snooze provides a server and VM failure notification API that can be directly used by the Monitoring Manager (thus with Snooze, no monitoring daemons need to be executed in the VMs). EC2 compatible Cloud (like Openstack [START_REF]OpenStack project[END_REF]) are supported as well. OpenStack does not provide a failure notification interface and thus the cloud-agnostic monitoring service is used.

Checkpoint Manager and Storage System

The Checkpoint Manager depicted in Figure 1 enables different storage systems to be plugged into the CACS service. The current implementation of the service is stateless and supports two storage systems: (1) NFS and (2) S3. NFS is suitable for small-scale deployment and mostly the prototyping process. S3 is the de facto standard API of Amazon Web Service for manipulating stored objects. Supporting S3 gives CACS the compatibility with the major Cloud providers, but also with other solutions such as Ceph.

Since checkpoint images may be generated periodically, under application control, or by the end user, a decision was made to save checkpoint images asynchronously. The Checkpoint Manager is not aware of the existence of checkpoint images until a restart is required. At that time, the Checkpoint Manager will choose the most recent checkpoint image, by default, but a user may also specify an earlier image.

Monitoring Manager

Some cloud platforms support an external API for monitoring if the virtual machines are alive. However, those cloud-specific mechanisms are not sufficiently flexible. Our goals are three fold:

(1) being cloud-agnostic, (2) testing the liveness of the VMs and ultimately (3) testing the "health" of the application.

The concept of health is application-specific. An application may fail due to unreachability of a computer node, insufficient memory, internal busy waiting within an application, bugs in the application code, issues induced by the execution context, the reception of spurious signals such as SIGCHILD and SIGPIPE or a myriad of other causes. A user-defined application-specific routine can define and test the application's health using a function hook offered by CACS.

The current implementation is based on a binary broadcast tree for each application. Each node of the broadcast tree is represented by a daemon, which calls the user's hook function to determine if the processes on that node are healthy. A standard broadcast tree then allows the root node to report a list of nodes that are unhealthy or unreachable to the Monitoring Manager. If problems are reported, the Monitoring Manager interacts with the Application Manager to trigger an application recovery.

There are two cases:

1. VM failure: A VM is unreachable. The CACS reserves a new VM from the underlying cloud infrastructure and restarts the application from a previous checkpoint.

2. Application failure: If all virtual machines are reachable, the application itself may still be reported as unhealthy. As an optimization, one then kills the processes of the application within their virtual machines, and restarts the application processes within their original virtual machines.

Inria

Resilience: Avoiding Single Points of Failure

The CACS service should be resilient to node failures. Its managers are stateless thus they can be easily restarted in the event of a failure. For high availability purpose, traditional server replication and failover approaches leveraging Apache Zookeeper [START_REF] Hunt | Zookeeper: Wait-free coordination for internet-scale systems[END_REF] can extend the current design in this area. The coordinators database could be implemented relying on a NoSQL reliable distributed database technology such as Cassandra or MongoDB that do not exhibit any single point of failure. The stable storage properties of the checkpoint storage are guaranteed through the use of a fault-tolerant distributed file system (e.g. Ceph) that provides persistent and highly available storage. The Snooze IaaS cloud management system has been designed to be highly available in the event of simultaneous failures [START_REF] Feller | Snooze: A scalable and autonomic virtual machine management framework for private clouds[END_REF]. Nevertheless, it does not ensure automatic virtual clusters recovery in the event of the failure of the server hosting one of their VMs. By integrating the CACS service in Snooze, computations run in virtual clusters can be automatically restarted in the event of a failure. Users of the enhanced Snooze system can enjoy both reliable application execution and a highly available IaaS cloud tolerating multiple simultaneous failures of physical machines hosting VMs and/or VM management services.

Other Implementation Details

The CACS service is implemented in Java and makes use of the scalable RESTlet [START_REF]Restlet: RESTful web framework for java[END_REF] framework to expose its API. The users requests are mostly treated in background using a pool of threads to optimize the parallelization and the responsiveness of the API. In the current implementation the coordinators database is stored in memory. The provision manager uses parallelization of SSH connection to act on virtual clusters.

Experimental Evaluation

The experiments are divided into four parts: scalability with application size up to 128 nodes using Snooze as a testbed (Section 7.1); resource consumption of the CACS service, including the performance of the monitoring system (Section 7.2); a performance study of migration between different clouds or between desktop and cloud (Section 7.3); and a study of the cloud-agnostic feature of CACS as applied to Snooze and OpenStack (Section 7.4).

The evaluation of the system was conducted on the Grid'5000 [START_REF]The Grid'5000 experimentation testbed[END_REF] testbed. A typical workflow for experimenting on the platform is to reserve physical nodes, then to deploy a Linuxbased environment, and finally to deploy and configure the desired software stack. The Debian Wheezy distribution (3.2.0-4-amd64 Linux kernel) served as the base environment for deploying Snooze (version 2.1.6) and Ceph storage (Firefly). Ubuntu 12.04 (kernel version 3.2.0-24-generic) was used for deploying Openstack (Icehouse). On the two clouds we used an Ubuntu 13.10 x86_64 base image, preconfigured with the DMTCP distribution (version 2.3). Both clouds use KVM/QEMU.

Scalability with Application Size

The scalability test was conducted using Snooze configured with more than 400 vCPUs and nearly 1 TB memory available, enough for holding more than 128 VMs, each of which requires one virtual core and 2 GB of memory. The NAS MPI test for LU (Class C) was employed [START_REF] Bailey | The NAS parallel benchmarks[END_REF]. Each MPI ran on a separate VM. We measured the performance for three phases: time to finish the application submission, time to perform a checkpoint, and time to perform a restart. Figure 3 shows that creation of the virtual machines and commands execution (provisioning, checkpoint, restart) require significant time. Time for submission depends strongly on the underlying infrastructure used (see Section 7.4 for more details), while the latter two times are related to the number of virtual machines involved in the application. Figure 3a shows the performance for application submission, which includes two steps: the underlying cloud allocates the VMs; and the CACS service provisions the VMs. The proposed CACS implementation optimizes the command execution mechanism through: (1) the parallelization of the SSH connections; and (2) re-use of the connections of the open SSH sessions. As a result, increasing the number of nodes increases only slightly the time for executing commands, up until the configured maximum limit of SSH connections is reached. This occurs after [START_REF]Restlet: RESTful web framework for java[END_REF] The time for a single checkpoint is shown in Figure 3b. Also, Table 2 shows the checkpoint image size as the number of nodes varies. Here, the primary workload contains two parts: Inria DMTCP writes the checkpoint image to local storage; and each VM uploads the image to the remote file system. Figure 3c illustrates the performance for restart. In this case, the trend becomes unstable for large number of nodes. This is due to network traffic when all nodes try to simultaneously download the checkpoint images. As a consequence, restarted processes do not join the computation concurrently, leading to jitter and less reproducible timings for DMTCP restart.

Resource Consumption and Monitoring System

This section focuses on the resource consumption of the CACS service, as well as the performance of the monitoring system. They share the same experimental configuration: for Snooze, 7 servers hosting VM management services and 12 servers hosting VMs (264 cores in total) were deployed. The target application used was dmtcp1, a single-process lightweight application found in the DMTCP test suite [START_REF] Ansel | DMTCP: Transparent checkpointing for cluster computations and the desktop[END_REF].

Resource Consumption of the Service

In this experiment, 100 applications were submitted to the CACS service, with one new application submitted every second. The network consumption and memory usage are shown in Figure 4a and Figure 4b, respectively. The vertical line at 100 seconds shows when the 100 applications had been submitted, but were not necessarily executing yet. Both figures show a decreasing trend as processing continues. Figures 4a and4b can be understood better through a review of the CACS implementation. The CACS service maintains a thread pool to handle incoming submissions. Theoretically, it can concurrently handle as many applications as there are threads in the thread pool (100 in this experiment). But the underlying cloud infrastructure has its own limitation: most clouds can handle a relatively small number of applications concurrently. More generally, assume that the cloud can handle n submissions concurrently, implying that there are n threads running SSH commands on the VMs provided by the cloud. Meanwhile, there are m threads polling the cloud front-end as it causes the VMs to be built. Assume also that the network resource consumed by a polling thread and an SSH thread are both constants, namely, c_1 and c_2. Based on these assumptions, we conclude that at any given time, the network traffic is:

mc_1 + nc_2.
In our case, m is initially 100. Since VMs are processed at a uniform rate, m will decrease at a uniform rate, thus explaining the linear trend in Figure 4a. The same analysis also explains the decreasing trend seen in Figure 4b.

Performance of the Health Monitoring System

The health monitoring system was discussed in Section 6.3. To measure its performance, we submitted applications with varying numbers of VM requests, and recorded the time required to finish one round-trip for a heartbeat (employing the binary broadcast tree described earlier). Figure 4c shows the result: the time to finish one heartbeat round-trip is logarithmic in the number of nodes, as expected. This provides strong evidence that the broadcast tree implementation consumes few network resources and scales to support large distributed applications.

Migration Evaluation

Migration of distributed applications are important in the real world. The CACS service is evaluated in two migration scenarios. Section 7.3.1 evaluates the cloudification of an NS-3 [START_REF]Ns-3 simulator[END_REF] application. NS-3 simulations are known for requiring long periods of time, and thus are good candidates for migration from commodity hardware to the cloud. Section 7.3.2 demonstrates the migration of applications between two distinct clouds: Snooze and OpenStack.

From Hardware to Cloud

Cloudification refers to migrating a conventional desktop or laptop application to the cloud. Statistics were obtained for migrating an NS-3 application from a physical machine to the Open-Stack destination cloud. The target application was tcp-large-transfer from the NS-3 distribution. The parameters of the application were set to simulate a 1 Gb transfer rate transferring 2 GB of data over a period of 30 seconds. The application was checkpointed after 10 seconds. A 50-line Python script invokes the CACS service, which checkpoints on the current machine and restarts in the destination cloud. The application contains a single process and the checkpoint image was approximately 260 MB. Application restart on OpenStack required 21 seconds. Note that in the destination cloud none of the VMs have NS-3 installed. This was not needed, since the NS-3 libraries were transported to the destination cloud as part of the checkpoint images. Next, application migration between Snooze and OpenStack was studied. Two instances, CACS-Snooze and CACS-Openstack, were deployed each relying on its corresponding IaaS platform. The target application is dmtcp1, the same as in Section 7.2. 40 different instances of the application were incrementally started on CACS-Snooze and then cloned to CACS-OpenStack using a 90-line Python script. The script checkpoints on the current cloud and restarts on the destination cloud. The experimental setup used a single instance of Ceph-based storage for both services, because both clouds were deployed on Grid'5000. Alternatively, two distinct storage systems could have been used as well with no modification. The application checkpoint periodicity was set to 60 seconds. The checkpoint image sizes were approximately 3 MB each.

Figure 5 depicts the overall network utilization at the storage level. It shows a linear increase of network utilization after start of the submissions. A plateau indicates that the applications' checkpoint images were received and stored and no submissions remain. The migration phase lasts for 2.5 minutes. The network utilization during this phase increases due to the data transfer of the checkpoint images. Note that the time to transfer checkpoint images from CACS-Snooze to CACS-OpenStack is negligible in this case, due to the small size of checkpoint images. The network utilization then reaches another plateau, indicating that two instances of each application are now running on the two different clouds (80 applications in total). After a certain period of time, all applications are terminated.

The experiment also demonstrates the ability of the CACS service to handle numerous concurrent restart requests (up to 40 requests).

Comparison of Different IaaS Technologies

Next, we compare the performance of CACS, when targeted toward two distinct cloud management systems: Snooze and OpenStack. The configuration for Snooze is the same as in Section 7.1, while OpenStack is configured with the same computing resources. Figure 6 reports the submission times, including both the time for the IaaS to process the VM submissions, and the time for the CACS service to provision the VMs. Figure 7 reports the checkpoint and restart times. Note that the same checkpoint policy was used for both clouds. Hence, the checkpoint sizes are the same (see Table 2). This implies that the uploading time during checkpoint and the downloading time during restart should be comparable, except to the extent that unless different network traffic conditions exist during the two phases. For this reason, Figure 7 reports a single time for checkpoint/restart, since the times for checkpoint and restart are comparable. Figure 6 shows that although the underlying IaaS systems are different, the time for the CACS service to provision the VMs remains comparable. In contrast, the time for different IaaS systems to process VM allocation differs greatly. The preceding breakdown into CACS-specific and IaaSspecific times illustrates that the CACS service is able to support different cloud management systems, with little or no CACS-specific difference in performance.

Figure 7 shows a similar trend, except that the restart time for OpenStack is not stable. This occurs for a pragmatic reason: normally, OpenStack recommends that network management and application network be located on different networks. However, the limitations of the Grid'5000 testbed forced the placement of both types of network data on the same network. This leads to data variability seen in the figure. We first review previous work on application checkpointing and VM snapshot mechanisms. We then study existing approaches for reliable application execution in clouds.

Options for Checkpointing Distributed Applications

In addition to DMTCP, several other checkpointing packages are in common use today. The survey [START_REF] Egwutuoha | A survey of fault tolerance mechanisms and checkpoint/restart implementations for high performance computing systems[END_REF] describes several checkpoint/restart implementations for high performance computing.

More generally, we review the checkpoint-restart packages in widespread use today.

For distributed computation, most checkpointing services today were built around MPIspecific checkpoint-restart services. Unfortunately, this was not an option for the current work, since a cloud-agnostic checkpointing service must also be application-agnostic. Nevertheless, historically there has been much effort toward MPI-specific custom checkpoint-restart service. This came about when InfiniBand became the preferred network for high performance computing, and there was still no package for transparent checkpointing over InfiniBand. Examples of checkpointrestart services can be found in Open MPI [START_REF] Hursey | The design and implementation of checkpoint/restart process fault tolerance for Open MPI[END_REF] (CRCP coordination protocol), LAM/MPI [START_REF] Sankaran | The LAM/MPI checkpoint/restart framework: System-initiated checkpointing[END_REF] (now incorporated into MVAPICH2 [START_REF] Gao | Application-transparent checkpoint/restart for MPI programs over InfiniBand[END_REF]), and MPICH-V [START_REF] Bouteiller | MPICH-V project: a multiprotocol automatic fault tolerant MPI[END_REF]. Each checkpoint-restart service disconnected from the network prior to checkpoint, called on a single-node checkpointing package such as the kernel-based BLCR [START_REF] Hargrove | Berkeley Lab Checkpoint/Restart (BLCR) for Linux clusters[END_REF], and re-connected after restart.

The current work is based on a new approach, implemented within DMTCP, which enables transparent checkpointing over InfiniBand [START_REF] Cao | Transparent checkpoint-restart over Infini-Band[END_REF] as well as TCP. This uniformly supports both MPI and other distributed applications.

Mechanisms Based on VM Snapshots

Virtual machine snapshots provide an alternative for checkpointing. The well-known packages KVM/QEMU, VirtualBox, and VMware all support snapshots of virtual machines. However, the choice of a particular virtual machine for a particular cloud platform is contrary to the goal of a cloud-agnostic service in this work. Furthermore, saving just the application is more efficient than saving an entire virtual machine, in part due to the smaller memory footprint of a bare application.

Fault Tolerance and Efficiency in the Cloud

There exist several alternative approaches to fault tolerance in the Cloud. Tchana et al. argue for shared responsibility between provider and user [START_REF] Tchana | Approaches to cloud computing fault tolerance[END_REF]. Zhao et al. follow a middleware approach [START_REF] Zhao | Fault tolerance middleware for cloud computing[END_REF]. Egwutuoha et al. take a process-level redundancy approach [START_REF] Egwutuoha | A fault tolerance framework for high performance computing in cloud[END_REF]. Di et al. present an adaptive algorithm to optimize the number of checkpoints for cloud-based applications [START_REF] Di | Optimization of cloud task processing with checkpoint-restart mechanism[END_REF].

Nicolae et al. show how to checkpoint an MPI application using distributed virtual machine snapshots using the BlobSeer distributed repository [START_REF] Nicolae | BlobCR: Efficient checkpoint-restart for HPC applications on IaaS clouds using virtual disk image snapshots[END_REF]. This approach is MPI-specific, since it employs the MPI checkpoint-restart service with BLCR (see Section 8.1 for a discussion of MPI checkpoint-restart services). Kangarlou et al. [START_REF] Kangarlou | VNsnap: Taking snapshots of virtual networked infrastructures in the cloud[END_REF] and Garg et al. [START_REF] Garg | Checkpoint-restart for a network of virtual machines[END_REF] each show how to take a distributed snapshot of virtual machines. Kangarlou et al. base this on a modification of Xen's live migration, while Garg et al. employ DMTCP to take a distributed snapshot of KVM/QEMU virtual machines. The last three investigations ( [START_REF] Nicolae | BlobCR: Efficient checkpoint-restart for HPC applications on IaaS clouds using virtual disk image snapshots[END_REF], [START_REF] Kangarlou | VNsnap: Taking snapshots of virtual networked infrastructures in the cloud[END_REF], [START_REF] Garg | Checkpoint-restart for a network of virtual machines[END_REF]) contrasts with the cloud-agnostic (and application-agnostic) approach employed here by directly checkpointing the processes with their network connections.

Several works study detection of failure modes [START_REF] Schroeder | A large-scale study of failures in high-performance computing systems[END_REF][START_REF] Xiong | A self-tuning failure detection scheme for cloud computing service[END_REF]. The approach of the Gamose system [START_REF] Ropars | Gamose: An accurate monitoring service for Grid applications[END_REF] for monitoring the health of Grid applications can extend the CACS checks for application health without requiring application hooks. Such a system relies on interposing on systems calls, and does not require any modification of the operating system.

The work of Marshall et al. [START_REF] Marshall | Improving utilization of infrastructure clouds[END_REF] demonstrates the utility of backfill virtual machines in maintaining a high utilization rate for the processors of the cloud. The backfill virtual machines can be combined with a checkpointing policy so as to always guarantee a supply of checkpoint images that can be restarted on demand to instantiate the backfill virtual machines.

Conclusion

The Cloud-Agnostic Checkpointing Service demonstrates checkpointing as a service on top of heterogeneous IaaS cloud systems in an environment of multiple heterogeneous clouds. A key design principle of CACS is that it is built around the DMTCP mechanism for taking checkpoints of distributed processes, rather than employing distributed VM snapshot mechanisms. This creates a cloud-agnostic service that is independent of the cloud platform, and independent of the cloud's choice of virtual machine technology. Preliminary experimental evaluations demonstrate portability between two IaaS cloud management systems and demonstrate scalability with the number of applications and the application size. The CACS service also supports migration between heterogeneous clouds, and cloudification, migration from a traditional environment to the cloud. In our next steps, we will further improve the scalability of the CACS service, study its efficiency in different computing environments varying the resource, VM and storage management systems, and experiment it with a broader range of distributed applications.

Inria

3. 1

 1 Why Using a Process-level Checkpointer rather than VM Snapshots?

Figure 1 :

 1 Figure 1: Cloud Checkpointing Service Architecture

Figure 2 :

 2 Figure 2: CACS Coordinator states

Figure 3 :

 3 Figure 3: CACS over Snooze

  time of monitoring (c) Performance of the monitoring system (Note: logarithmic x-axis)

Figure 4 :

 4 Figure 4: CACS resource evaluation

Inria

7. 3 . 2 From

 32 Cloud to Cloud

Figure 5 :

 5 Figure 5: Migration performance of 40 applications

Figure 6 :

 6 Figure 6: Comparison of submission time

Figure 7 :

 7 Figure 7: Comparison of Checkpoint/Restart time

Table 1 :

 1 REST API description

	coordinators resource
	GET /coordinators		returns the list of coordinators known by the system
	POST /coordinators		add a new coordinator to the system
	coordinator resource
	GET /coordinators/:id	returns the information of the coordinator with id : id
	DELETE /coordinators/:id	delete the coordinator
	checkpoints resource
	GET	/coordina-	returns the list of the checkpoints of the coordinator
	tors/:id/checkpoints
	POST	/coordina-	trigger a checkpoint for the coordinator or upload a check-
	tors/:id/checkpoints		point image
	checkpoint resource
	GET	/coordina-	returns the information of a checkpoint
	tors/:id/checkpoints/:id
	POST	/coordina-	restart the coordinator from the checkpoint
	tors/:id/checkpoints/:id
	DELETE	/coordina-	delete the checkpoint
	tors/:id/checkpoints/:id

Table 2 :

 2 nodes in the current setup. Checkpoint image sizes for the NAS benchmark lu.C, under different configurations. The checkpoint image size is for a single MPI process.

	Number of processes	1	2	4	8 16
	Ckpt size (MB)	655 338 174 92 49

RR n°8633

route des Lucioles -BP 93 06902 Sophia Antipolis Cedex Publisher Inria Domaine de Voluceau -Rocquencourt BP 105 -78153 Le Chesnay Cedex inria.fr ISSN 0249-6399

Acknowledgment

Experiments presented in this paper were carried out using the Grid'5000 experimental testbed, being developed under the INRIA ALADDIN development action with support from CNRS, RE-NATER and several Universities as well as other funding bodies (see https://www.grid5000.fr).


S Carpentier
email: scarpentier@univ-paris12.fr

R Moilleron

C Beltran

D Herve

D Thevenot

Quality of dredged material in the river Seine basin (France). II. Micropollutants

Keywords: Dredged material, Sediments, Quality, River Seine basin, Heavy metals, PAH

Dredging rivers is needed to ensure safe navigable waters, rivers and waterways. To anticipate the management of dredged materials in the case of the river Seine basin, the quality of the sediments in the river is checked every 3 years before dredging operations. The river Seine Basin is heavily submitted to pollution pressure from nearby industrial activities and urban expansion of Paris and its region. Here, the micropollutant content of the sediment sampled in 1996, 1999 and 2000 before dredging is discussed compared to regulatory standards. The results indicate that most of the sediment samples from the river Seine basin are lightly to moderately contaminated with organic and inorganic micropollutants (heavy metals, PAH, PCB), which makes the management after dredging easier. This pollution is strongly correlated with the organic matter content and to the fine fraction (-50 mm) of the sediment. These results can lead to other management options than the ones already used in the river Seine basin: (1) dumping of lightly to moderately polluted sediments in quarries; and (2) physical treatment (sieving, hydrocycloning) of contaminated sediments issued from 'hot spots'.

Introduction

The increasing urban environmental pollution and human impact leads to water quality deterioration. With the release of polluted water into the receiving water bodies, contaminants are absorbed onto suspended particles and subsequently accumulated in the underlying sediment [START_REF] Hauge | Remediation of contaminated sediments in Oslo Harbour, Norway[END_REF][START_REF] Lau | Contaminant release from sediments in a coastal wetland[END_REF]. Hence, dredging contaminated sediments means removing the pollution which is contained in the sediment.

Dredging techniques vary depending on the volume, texture, water content and grain size of the sediments to be removed. The method that causes the least environmental impact on the water a quality, during dredging operations, is the hydraulic method. However, mechanical dredging yields materials containing high solid levels: this is an important criteria given for better management of dredged material (DM), i.e. avoiding large water volumes management [START_REF] Hauge | Remediation of contaminated sediments in Oslo Harbour, Norway[END_REF].

Once dredged, DM can be treated, valorised, or disposed. Before any management decision, it is necessary to characterise the DM chemically, physically and mechanically [START_REF] Boutouil | Devenir des vases et boues de dragage: solidification et stabilisation[END_REF]. However, the economic, political context and management issues, such as the lack of disposal sites, can interfere with the decision provided by the characterisation of DM. In the specific case of the river Seine basin, mechanical dredging from a boat was chosen to remove approximately 150 000 m 3 of sediment per year from the Seine basin. Dredging in the Seine basin is mainly 'maintenance dredging' for navigation. DM is then dumped into wet disposal sites, i.e. disused quarries, downstream Paris. From 1992 to 1998, the site of Triel and from 1999 to 2001, the site of Rouillard have been filled with the DM extracted from the river Oise downstream Compiegne and from the river Seine downstream Vitry (Fig. 1). According to an estimate in the 1980s by the US Army Corps of Engineers [START_REF] Combs | Chemical properties and mineralogical characteristics of selected dredged material[END_REF] and in a recent study in the Netherlands [START_REF] Cuypers | Characterisation of PAH-contaminated sediments in a remediation perspective[END_REF], approximately one third of all dredged materials are contaminated by municipal sewage, industrial discharges and agricultural runoff.

In a previous paper [START_REF] Carpentier | ´Quality of dredged material in the river Seine basin (France) I. Physico-chemical properties and major contamination[END_REF], we characterised the physico-chemical properties and major contamination patterns of the sediments sampled from the river Seine basin before dredging. This work revealed the wide variety of the sediment quality, particularly the carbon content and the grain size, along the river Seine basin. The analysis of porewaters revealed high concentrations in ammonium that might lead to a management concern: in fact, the dumping of such sediment after dredging might induce an increase of ammonium concentrations in the receiving waters at the disposal sites [START_REF] Carpentier | ´Ímpact environnemental de la mise en depot de materiaux ´ˆd e dragage (cas du bassin de la Seine)[END_REF]. After correlation analysis and geographic distribution study, the impact of the great Parisian region (including Paris itself and close counties) was not clearly observed. This impact was only observed when the location of the sediment sample was far enough, i.e. approximately 100 km from the urban andyor industrial sources. For example, samples V30 or V18 on Marne and Seine river, respectively, upstream Paris showed very different organic matter contents compared to S1 or S6 on Seine river downstream Paris. In order to improve our knowledge on the quality of river Seine basin sediments, we also analysed the micropollutants in the sediments. Here, we are not only interested in the sediment quality itself, but we are also concerned about the quality of the DM that it becomes, after extraction from the river bed, and its fate once moved to another receiving environment. For that reason, we also analysed micropollutants in porewaters of the sediments and leachates obtained with the same sediment samples. The study of leachates is, in the case of disposal, one of the techniques recommended by the French standard NF XP X 31-210 for assessing the impact of materials on their close environment, after dumping. The study of porewaters was also performed in order to assess the potential release of pollutants that might occur during the management of DM. The aim of this work is to translate these sediment and pore quality data into dredging and treatment strategies for the river Seine basin.

Material and methods

Sediment collection

The sampling procedure has been fully described previously. Briefly, samples were collected from the bottom of the rivers Seine, Oise and Marne by handcore sampling (20-50 cm depth depending on the DM quality)( Fig. 1). Samples were collected in May and June 1996, April 1999 and May 2000 in representative areas determined by the Navigation Services of the Seine basin (SNS), according to the dredging needs for the following year, resulting from bathymetric survey of the river. Once cored, sediment samples were transferred into fully filled and closed glass containers (1l ) and were kept in a store room (4 8C) for 48 h maximum before homogenisation and analysis.

Methods

Different parameters were analysed both on the sediment (Table 1) and in the leachates obtained with the same sediment samples. Leachates were resulting from mixing 200 g of bulk sediment for 2 4hw i t h2lo fdistilled water, according to the French AFNOR standard XP X31-210. Parameters were also measured on pore waters. The method to extract pore waters is described in a previous paper [START_REF] Carpentier | ´Quality of dredged material in the river Seine basin (France) I. Physico-chemical properties and major contamination[END_REF]. Most parameters were measured following the French standard procedures i.e. AFNOR (Table 1). All samples were analysed by laboratories certified by the French Ministry of the Environment, i.e. certified by the COFRAC (Comite Francais d'Accreditation). For ´í nternational quality control, the COFRAC calibration certificates co-operates with other European calibration services (the European co-operation for Accreditation, EA). The harmonisation of the accreditation criteria and procedures are orientated towards the European standards for calibration and testing laboratories and their assessment and accreditation (EN ISOyIEC 17025 and EN 45 000 series). The detection limits for inorganic and organic micropollutant content of sediment samples were chosen in order to be significantly below regulatory standards (Table 1).

Results and discussion

Sediment quality

Heavy metals

The average metal content of the sediment collected in various dredged areas of the river Seine basin (Table 2 andTable 3) is generally slightly lower than the average values found in the total suspended solids (TSS) from the river Seine basin [START_REF] Meybeck | La Seine en son bassin, Fonctionnement ecologique d'un systeme fluvial anthropise[END_REF]. In fact, in the case of Zn, levels vary from 190 to 700 mg g in the y1 TSS, whereas in the sediment analysed in the present study, concentrations vary from 40 to 560 mg g . The same difference is observed for Cd, y1 Cu, Pb. This slight difference can be explained by the nature of the sediment itself. As we found out previously [START_REF] Carpentier | ´Quality of dredged material in the river Seine basin (France) I. Physico-chemical properties and major contamination[END_REF], grain size of sediments from the river Seine basin, and particularly the percentage of particles below 50 mmi s on average 20%. In the study concerning TSS, this percentage was ranging from 40 to 45%. This may explain the higher heavy metal content in TSS samples, compared to sediment samples, because heavy metals are preferably adsorbed on fine particles [START_REF] Evans | The PAH and organic content of sediment particle size fractions[END_REF][START_REF] Warren | Suspended particulate grain size dynamics and their implications for trace metal sorption in the Don River[END_REF][START_REF] Perrin | La gestion des produits de dragage en provenance des voies d'eau interieures[END_REF]. However, the difference observed between sediments and TSS from the river Seine basin remains small compared to the difference of heavy metals content between sediments sampled at different locations of the Seine basin.

Concentrations of metallic pollutants found in the sediment sampled in the Seine basin are low (210 mg g on average for Zn) compared to the y1 values found in French Northern rivers 'Petite Marque' and 'Riez Simon' near Lille (59) [START_REF] Ruban | Migration of micropollutants in a dredging amended soil in Northern France[END_REF] which contain on average 1180 mg g for Zn. This difference might be due to the y1 characteristics of the sediment (TOC for the North of France rivers83 g kg whereas average TOC y1 for this studys3 7gk g ). In the case of sedi-y1 ments from canal Gent Terneuzen in Belgium [START_REF] Cauwenberg | Flotation as a remediation technique for heavily polluted dredged material. 1. A feasibility study[END_REF], Zn concentrations can average fine particles for this studys21%). This difference is also observed for other heavy metals such as Cu, Pb, Cd, Ni. Hence, we can assume that sediments from the river Seine basin are less polluted with heavy metals than other rivers or canals situated in industrialised and densely populated areas, this difference being mainly due to the characteristics of the sediment such as the grain size or the organic content which are linked to the heavy metals contents.

To give a general idea of the metal contamination of sediments in the river Seine basin, we compared metal levels to the limits given by the Dutch decree on the quality of DM (circular on target values and intervention values for soil remediation, Ministry of Housing, Spatial Planning and Environment, updated 04y02y2000) which is often used as a reference in Europe. This decree gives two kinds of values: 'A' for Alert value which is (SD), and coefficient of variation in % (CV) of the characteristics given in Table 5.

the target value for sediments; and 'I' for 'Intervention' value for which sediments are considered as contaminated (Table 4). Most samples present metal contents either inferior to the 'A' limit, or between 'A' and an intermediate value w(AqI)y 2)x for which sediments show moderate contamination. Fig. 2 shows the distribution of the number of sites showing different quality classes considering the Dutch decree. A few samples present concentrations above this average value (V04, V06, V09 for Hg, V04, V07, S14 for Zn and V03, V07, S10, S12, S14, S15, S16 for Cu), and only two samples show concentrations above the 'I' level: S1 and V02 for Hg. As a result, this comparison with the Dutch decree limits and the comparison with other values found in natural environments tend to indicate that most of the sediment samples from the river Seine basin are lightly to moderately contaminated with heavy metals.

Organic micropollutants

Total PAH levels, i.e. sum of 16 species listed by USEPA, found in the river Seine basin sediments (Table 5 andTable 6) are similar to the values in TSS previously collected in the river Seine [START_REF] Meybeck | La Seine en son bassin, Fonctionnement ecologique d'un systeme fluvial anthropise[END_REF]. The sediments sampled in the present study contain 6.7 mgg y1 (median) of total PAH with a maximum of 84 mg g and a minimum of 1.4 mg g . TSS containing y1 y1

from 6 to 11 mgg (median) of total PAH from y1 upstream Paris to the sampling site at Chatou, downstream Paris, correspond to the site S2 in the present study (Fig. 1). Unlike heavy metals, total PAH contents in sediments and in TSS present similar levels.

Total PAH in the sediments from the river Seine basin show average values of 10.9 mg g . In the y1 North of France, a very industrialised region, river sediments contain far higher total PAH contents that can reach 770 mgg [START_REF] Ruban | Migration of micropollutants in a dredging amended soil in Northern France[END_REF].

y1
Compared to the alert and intervention values from the Dutch decree (04y02y2000), most samples issued from the river Seine basin present concentrations below 'A' value andyor between 'A' and w(AqI)y2x values (Fig. 2). Still, some samples show values superior to w(AqI)y2x, i.e. S1, S8, S13 and one sample shows a concentration above the 'I' intervention value, S6. But out of 38 samples, we can assume that the majority of the sediment samples are lightly to moderately contaminated if we consider the Dutch decree, and by comparing the case of the river Seine basin to other urban river basins. PCBs were also measured in this survey. Total PCB contents obtained in Seine sediment samples collected in 1992 to 1995 [START_REF] Meybeck | La Seine en son bassin, Fonctionnement ecologique d'un systeme fluvial anthropise[END_REF] varied from 500 to 3000 ng g . In the sediments y1 analysed for the present survey, total PCB content varied between detection limit levels (5n gg ) y1 and 1300 ng g , with the exceptional site V03 at y1 the Seine-Oise river junction, showing a concentration of 22 900 ng g . This exceptional value y1 at site V03 may be due to the influence of the Oise river and its associated pollution which joins the Seine river at this site, and also the industries and combined sewer overflows upstream at this site on the Seine river. Thus, we can assume that this range of total PCB concentrations corresponds to the one previously observed on the sediments measured in the river Seine basin [START_REF] Meybeck | La Seine en son bassin, Fonctionnement ecologique d'un systeme fluvial anthropise[END_REF]. Compared to other river basins, sediments from the river Seine basin show lower total PCB amounts (means1.4 mgg ) than sediments from y1 the Rhine river in the Netherlands which presents an average level of 5.5 mgg (Van Der Hurk et y1 al., 1997). Again, in that Dutch study, sediments presented loss on ignition of 14% on average, whereas in this study, the mean organic matter content is of only 8%. This difference might explain the PCB contents since PCB contents vary as a function of organic matter contents [START_REF] Fowler | Critical review of selected heavy metal and chlorinated hydrocarbon concentrations in the marine environment[END_REF]. Compared to the Dutch decree, most samples from the river Seine basin showed total PCB concentrations below the 'A' value and between 'A' and w(AqI)y2x intermediate value (Fig. 2). Nevertheless, the concentration of sample V08 on Oise river was above w(AqI)y2x and concentrations of samples V03, V04 and V07 on Seine river downstream Paris were above 'I' value. Again, concerning the total PCB level, as for heavy metals and PAH, we can state that most of the sediment samples from the river Seine basin are lightly to moderately contaminated compared to Dutch criteria.

.009 -0.1 -0.1 0.2 -1 -0.1 0.7 -0.01 -0.02 S8 -0.05 -0.02 -0.1 0.009 -0.1 -0.1 -0.1 -1 0.1 0.2 -0.01 -0.02 S9 -0.05 -0.02 -0.1 0.009 -0.1 -0.1 -0.1 -1 -0.1 0.2 -0.01 -0.02 V1 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 -0.1 -1 V2 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 -0.1 -1 V3 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 -0.1 -1 V4 -0.
-0.1 -0.1 -1 -0.1 0.3 -0.01 -0.02 S10 -0.05 -0.02 -0.1 -0.1 -0.005 0.1 -0.1 0.2 -1 1.1 -0.1 -1 -0.01 -0.02 S11 0.05 -0.02 -0.1 -0.1 -0.005 0.1 -0.1 -0.1 1.5 0.8 -0.1 -1 -0.01 -0.02 S12 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 0.5 1.1 0.3 1.6 -1 -0.01 -0.02 S13 -0.05 -0.02 0.6 -0.1 -0.005 0.3 -0.1 0.2 -1 2.4 0.1 -1 -0.01 -0.02 S14 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 0.2 1.6 0.4 -0.1 -1 -0.01 -0.02 S15 -0.05 -0.02 0.2 -0.1 -0.005 0.1 -0.1 0.2 -1 0.7 -0.1 -1 -0.01 -0.02 S16 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 0.3 1.6 0.4 0.1 -1 -0.01 -0.02 O10 -0.05 -0.02 0.3 -0.1 -0.005 0.2 -0.1 0.2 -1 1.5 -0.1 -1 -0.01 -0.02 O11 -0.05 -0.02 0.1 -0.1 -0.005 -0.1 -0.1 0.2 1.4 1.5 0.1 -1 -0.01 -0.02 O12 -0.05 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1 0.2 1.5 1.1 -0.1 1.5 -0.01 -0.02 O13 -0.05 -0.02 0.2 -0.1 -0.005 0.1 -0.1 0.2 -1 1.4 -0.1 -1 -0.01 -0.02 O14 -0.05 -0.02 0.3 0.2 -0.005 0.2 -0.1 -0.1 -1 1.3 -0.1 -1 -0.01 -0.02
We also measured pesticide, toluene and phenols contents in the sediments: we do not discuss these results in the present paper since most values were found below detection limits (Table 5 andTable 6).

Leachates and pore water quality

Concentrations of micropollutants in the leachates obtained from the river Seine basin sediments are mostly below detection limits (Table 7): exceptions are rare. We also measured micropollutants in porewaters. Concentrations were also frequently below detection limits (Table 8). From these results, we can assume that there is only a minor short term risk of micropollutants release by DM. Alternatively, we suggest that the leaching test performed by mixing a 100 gyl suspension of sediment, during 24 h, is unable to simulate sediment diagenesis under anoxic conditions. Thus, it is difficult to anticipate the behaviour of micropollutants once the sediment has been dredged, unless we monitor the evolution of dredged materials with time in situ [START_REF] Carpentier | Bilans et impacts de la mise en depot de ´ŝediments fluviaux urbains dans le bassin de la Seine[END_REF].

Geographic distribution and correlation analysis

Correlation analysis was performed to assess the probable link between micropollutants and physico-chemical parameters presented and discussed in a previous paper [START_REF] Carpentier | ´Quality of dredged material in the river Seine basin (France) I. Physico-chemical properties and major contamination[END_REF], as well as between micropollutants themselves (Table 9). The correlation between the sediments organic matter content and some heavy metals is significant (r)0.7, n)46, P-0.01): Cr; Ni; As; Fe; Al; and Mn; as well as the correlation between organic matter and total hydrocarbons (rs0.63, ns61, P-0.01). This kind of correlation has often been demonstrated in literature [START_REF] Irwin | Environmental Contaminants Encyclopedia[END_REF]. Also, as expected, fine particles percentage was correlated significantly to some heavy metal con-tents: Cr; As; Fe; Al; and Mn (r)0.7, n)46, P-0.01); and to Ni (rs0.47, ns71, P-0.01). Fine particles were also significantly correlated to total hydrocarbons (rs0.36, ns61, P-0.01). Concerning organic micropollutants and heavy metals, we found out that total hydrocarbon concentrations were significantly correlated (r)0.7, n)33, P-0.01) to some heavy metal concentrations: Cr; Zn; Ni; Cu; As; Al; and Mn, probably indicating the influence of industrial or urban runoff. But total PAH and total PCB levels were not correlated to one another or with heavy metals. A few heavy metals were correlated to one another: Cr with Zn; Ni; Cu; Fe; Al; Mn. The fact that Cr is correlated to Fe, Al and Mn, which are crustal metals, corresponds to the fact that part of Cr in the environment is natural. Its correlation with Zn, Ni and Cu could be related to the anthropogenic origin of Cr, since Ni, Cu and Zn are involved in many industrial processes [START_REF] Rodier | L'analyse de l'eau eaux naturelles, eaux residuaires, éau de mer[END_REF]. Fe, Al and Mn are strongly correlated (0.83-r-0.89) because they are crustal metals and, therefore, belong to the matrix of the sediments [START_REF] Rodier | L'analyse de l'eau eaux naturelles, eaux residuaires, éau de mer[END_REF], but their content is also strongly linked to the As one (0.91-r-0.94), which is quite unexpected. These results suggest As is both adsorbed onto organic matter and charged surfaces of clays [START_REF] Irwin | Environmental Contaminants Encyclopedia[END_REF].

We performed a geographic distribution analysis using Mapinfo Geographic Information System ᭨ in order to present a general overview of the micropollutant content of sediments along the whole river Seine basin, and to try and link the most polluted areas to the main point sources identified in the same region (combined sewer overflows were listed in Meybeck et al., 1998 and industrial effluents were inventoried for this study) (Fig. 3). Unlike physico-chemical parameters, micropollutants show a very clear pattern: highly contaminated sites are regularly situated in the same areas of the river Seine basin, whatever the micropollutant considered. Downstream all major source of pollutants, i.e. industrial effluent andyor combined sewer overflow sites, the sediment samples present higher micropollutant contents. Fig. 4 illustrates this relation with Zn: the eight 'hot spots' correspond exactly to a cluster of industries and waste water treatment plants as well as combined sewer overflow sites. We can state that these contamination distribution maps represent a recent fingerprint of diverse pollution, since the specific areas sampled for this study are dredged frequently and, thus, the surface sediment that has been sampled was present and contaminated for less than 3 years. It is important to note that similar distribution maps were also found for Cu, Pb, Cr, As, Hg, Ni, Cd and total hydrocarbons, and to a lesser extent, for total PAH and PCB and Fe, Al and Mn.

Conclusions

Before dredging operations within the river Seine basin, the quality of the sediments to be dredged is regularly checked (once every 3 years) in order to determine the management strategy of dredged materials. In this survey, we present the results obtained for samples collected in 1996, 1999 and 2000 and suggest dredging and management strategies. Depending upon the sediment contamination, the following strategies are recommended: (1) dumping of light or moderately polluted sediments in quarries referring to the limits given by the Dutch decree on target values and intervention values for soil remediation, Ministry of Housing, Spatial Planning and Environment, updated 04y02y2000; (2) identifying some 'hot spot' sites and give the sediments dredged here a separate cleaning (sieving, hydrocycloning) in order to discriminate highly contaminated fine particles from sand or gravel which can be reused.

Fig. 1 .

 1 Fig. 1. Part of the Seine basin concerned in this study and site codes corresponding to the sediment samples collected during 1996, 1999 and 2000 campaigns: 'Hot spots' i.e. sites of significant sediment contamination appear within circles.

Fig. 2 .

 2 Fig. 2. Statistical distribution of the number of sediment samples presenting a contamination in heavy metals or organic micropollutants below (-A) the Alert value of the Dutch decree on the quality of sediments, above ()I) the Intervention value of this decree, or within these two values.

  a

Fig. 3 .

 3 Fig. 3. Sites of major industrial effluents inventoried for this study and combined sewer overflows (listed in Meybeck et al., 1998) in the river Seine basin.

Fig. 4 .

 4 Fig. 4. Geographic distribution of Zn content (mgg ) in the sediment collected along the river Seine basin during 1996, 1999 and y12000 campaigns: highly contaminated sites correspond to the 'hot spots' (Fig.1) and to the sites of possible pollution release (Fig.3).

Table 1

 1 List of micropollutants determined in the sediment (S) sampled in 1996, 1999 and 2000, in the leachates (L) and in the pore water (P), methods used to analyse each parameter and detection limits (dl) for the different methods

	Analysis	Method	Analysis	Sample	dl (S)	dl (L)	dl (P)
					(mgg ) y1	(mgg ) y1	(mgl ) y1
	Total hydrocarbons	X 31-410 ISO TR 11046	IR	S, L, P	20	1	50
	Total PAH (16 EPA species)	NF T 90-115	HPLC	S, L, P	0.01	0.01 a	0.01
	Total aliphatic hydrocarbons		GCyFID	S, L, P	2	20 a	20
	Toluene	NF ISO 11423-1	GCyFID	S	0.1	nd	nd
	Pesticides	NF EN ISO 6468 T90-120	GCyMS	S	0.15	nd	nd
	Total PCB (6)	NF EN ISO 6468 T90-120	GCyECD	S	0.005	nd	nd
	As	NF EN ISO 11885	ICPyAES	S, L, P	5	0.05	5
	Cd	NF EN ISO 11885	ICPyAES	S, L, P	0.8	0.02	2
	Cu, Cr, Ni, Pb, Zn	NF EN ISO 11885	ICPyAES	S, L, P	5	0.1	10
	Al	NF EN ISO 11885	ICPyAES	S, L, P	5	1	10
	Fe, Mn	NF EN ISO 11885	ICPyAES	S, L, P	5	0.1	10
	Hg	XP T 90-113-2	Atomic	S, L, P	0.05	0.005	0.5
			fluorescence
	Phenolic compounds	Acidic extraction	GCyMS	S, L	2	nd	nd
	mgyl.

Table 2

 2 Metal content (mgg ) in the sediment collectedin 1996, 1999 and 2000

			y1
	Code Y a	As	Cd	Cr	Cu Hg	Ni Pb Zn Al	Fe	Mn Code Y a	As Cd	Cr Cu Hg	Ni Pb Zn Al	Fe	Mn
	V01		-0.8 -10	12	0.76 -5	32	70		S6	1999 -5	1.8		62	0.64	10 103 220	2600	3300	38
	V02		-0.8 -10	28 15.5	-5	50	98		S7	1999 -5	3		83	0.92	19	83 293	3800	8200	50
	V03	6.93 -0.8	46 172	1.61 22 194 535		S8	1999 -5	3		90	0.64	16	69 250	1800	7200	43
	V04	3.33 -0.8	24 102	6.31 -5 132 240		S9	1999 -5	1.5		54	0.65	20	70 225	2200 15 100	39
	V05		-0.8	24	80	2.78 -5 174 290		V1	1999 -5 -0.8	44	91	0.8	17	42 278
	V06		-0.8	22	92	5.55 -5 158 246		V2	1999	6 -0.8	48	96	0.8	18	9 295
	V07	5.69	6	46 122	2.5	20 278 563		V3	1999 -5 -0.8	13 -5 -0.05	-5 -55 8
	V08	4.08 -0.8	20	70	2.35 -5 152 236		V4	1999 -5 -0.8	25	29 -0.05	-51 28 8
	V09		-0.8 -10	64	5.9	-5 136 283		V5	1999 -5 -0.8	10 -5	0.1	-51 54 6
	V10		-0.8	20	68 -0.05 -5	74 168		V6	1999 -5 -0.8	16	26	0.192 -5	43 100
	V11		-0.8 -10	42 -0.05 -5	82 118		V7	1999 -5 -0.8	13	8	0.109 -51 24 3
	V12		-0.8 -10	16 -0.05 -5	48	52		V8	1999	6 -0.8	78	73	0.414 24	80 300
	V13		-0.8 -10	22 -0.05 -5 118	94		O1	1999 -5 -0.8		9	0.29	14	42	81	6600 17 000	15
	V14		-0.8 -10	10	0.37 -5	36	32		O2	1999 -5 -0.8		-5	0.09	6	24	39	6100	9400	9
	V15		-0.8 -10	14	0.27 -5	44	26		O3	1999 -5 -0.8		24	0.3	20	33 141	5900 14 500	25
	V16		-0.8 -10	60	1.28 -5 -5	76		O4	1999 -5 -0.8		16	0.3	17	28	99	5100 12 300	18
	V17		-0.8 -10	16	0.36 -5 -5	30		O5	1999 -5 -0.8		27	0.39	22	51 183	3100	2300	32
	V18		-0.8 -10	44 -0.05 -5 -5	54		O6	1999 -5 -0.8		14	0.3	8	32	86	6800	8600	16
	V19		-0.8 -10	12 -0.05 -5 -5	36		O7	1999 -5 -0.8		26	0.37	20	50 173	6900 18 300	30
	V20		-0.8 -10	14 -0.05 -5	56	80		O8	1999 -5 -0.8		32	0.45	20	58 185 12 900 11 200	32
	V21		-0.8 -10	14 -0.05 -5 214 260		O9	1999 -5 -0.8		28	0.44	21	53 103	5300 23 000	19
	V22		-0.8	28	68 -0.05 -5	86 238		S10	2000 11	0.91 36 114	0.53	20	80 247 28 661 29 177 469
	V23	3.35 -0.8 -10	28	0.31 -5	38	82		S11	2000	6 -0.8	11	23	0.18	9	44 116	6652	6643 243
	V24		-0.8	20	50	0.28 -5	72 144		S12	2000 13	1.33 48 131	0.56	28 107 355 32 778 34 240 495
	V25		-0.8	24	48 -0.05 -5	70 132		S13	2000 -5 -0.8	11	27	0.25	-5	64	87	3119	4676 199
	V26		-0.8 -10	20 -0.05 -5 -5	78		S14	2000 13	2.06 73 136	0.76	30 102 450 36 148 36 960 509
	V27		-0.8 -10	18 -0.05 -5	42	60		S15	2000 10	1.65 63 127	0.64	25	88 400 34 464 33 711 456
	V28		-0.8	20	38 -0.05 -5	58 118		S16	2000 12	1.66 63 120	0.65	26	83 380 30276 36 787 484
	V29		-0.8	20	26 -0.05 -5	32	88		O10 2000 11 -0.8	40	28	0.15	23	24 144 24 488 39 859 343
	V30		-0.8 -10	30 -0.05 -5	42	90		O11 2000	6 -0.8	34	28	0.15	17	39 136 15 886 21 756 356
	V31		-0.8	24	56 -0.05 -5	32 132		O12 2000 10 -0.8	41	32	0.17	20	30 179 25 105 32 261 379
	S1		-5	3		94 24	24 144 286 1800	9700 49 O13 2000	9 -0.8	35	31	0.23	16	33 191 21 337 31 955 419
	S2		-5	-0.8		56	0.49 16	71 188 3000	5600 33 O14 2000 12	0.92 49	39	0.26	24	38 225 32 588 38 650 481
	S3		-5	-0.8		30	0.23 14	62 122 5900	5300 22 O15 2000	7 -0.8	26	23	0.21	11	28 125	1562 15 496 358
	S4		-5	-0.8		85	0.56 15 198 414 5000	5600 70 O16 2000 11 -0.8	40	42	0.28	19	44 220 23 764 35 368 406
	S5		-5	1.3		60	0.51 21	73 210 2600 10 900 37 O17 2000	7 -0.8	30	32	0.28	14	35 171	4017 20 921 391
	See Fig. for sampling site location.
	a	Year of collection.

Number of samples (n), median (d ), first and last decile (d , d ), minimum and maximum (min, max), standard deviation (SD) and coefficient of variation in % (CV) of the data given in Table

2

. Table 4 Alert values (A) and Intervention values (I) for soil remediation (mgg ) Dutch circular, 04y02y2000, Ministry of Housing, Spatial Planning and Environment, Holland. PCB ssum of PCB 28, 52, 101, 118, 153, 180.

Table 5

 5 Organic micropollutant content (mgg ) in the sediment collectedin 1996, 1999 and 2000

					y1
	Code Y a	HC tot PA H tot Ali tot PCB tot Pesticides Toluene Phenols Code Y a	HC tot PA H tot Ali tot	PCB tot	Pesticides Toluene Phenols
	V01	3						S3	1999		13.0	14.6
	V02	118						S4	1999		11.3	33.1
	V03	522	6.66		22.9	-2	S5	1999		5.7	33.4
	V04	45 11.78		1.32	-2	S6	1999		83.8	55.2
	V05	213						S7	1999		19.1	133.1
	V06	243						S8	1999		22.6	24.3
	V07	98	4.78		1.33	-2	S9	1999		10.3	66.1
	V08	457	1.78		0.92	-2	V1	1999	388
	V09	65						V2	1999	214
	V10	427						V3	1999	21
	V11	269						V4	1999	121
	V12	66						V5	1999	24
	V13	57						V6	1999	21
	V14	357						V7	1999	63
	V15	71						V8	1999	46
	V16	111						O1	1999		1.4	12.4
	V17	56						O2	1999		2.1	23.4
	V18	24						O3	1999		3.5	22.7
	V19	121						O4	1999		3.5	44.9
	V20	117						O5	1999		5.9	51.9
	V21	745						O6	1999		6.2	11.1
	V22	440					-2	O7	1999		5.4	38.9
	V23	60	1.4		0.06		O8	1999		10.4	60.5
	V24	263						O9	1999		4.5	30.9
	V25	543						S10	2000	459	7.5	-2	0.025	0.91	1	1.1
	V26	87						S11	2000	44	6.2	-2	0.049 -0.15	-0.1	-2
	V27	12						S12	2000	918	4.8	-2	0.022 -0.15	2.6	5
	V28	64						S13	2000	90 23.7	6.9	0.012 -0.15	-0.1	-2
	V29	84						S14	2000 1135	7.7	4.4	0.094 -0.15	0.9	-2
	V30	114						S15	2000 1252 13.1	2.9	0.129 -0.15	0.4	-2
	V31	129						S16	2000	712	7.7	4.5	0.114 -0.15	1.4	-2
	V32	6						O10	2000	163	4.7	-2	0.006 -0.15	-0.1	-2
	V33	12						O11	2000	180	4.9	-2	0.018 -0.15	-0.1	-2
	V34	1014						O12	2000	343	3.7	-2	-0.005 -0.15	0.3	-2
	V35	584						O13	2000	342 12.7	5.7	0.064 -0.15	0.2	-2
	V36	225						O14	2000	367	5.9	13	-0.005 -0.15	0.2	-2
	V37	266						O15	2000	96	3.2	7.3	0.011 -0.15	-0.1	-2
	V38	295						O16	2000	380	8.5	8.1 -0.005 -0.15	0.5	-2
	S1			29.8	25.5				O17	2000	194	7.9	6.7 -0.005 -0.15	0.6	-2
	S2			18.4	28
	See Fig. 1 for sampling site location.
	a	Year of collection.
	even reach 3200 mg g	y1	due also to different
	characteristics (TOC for Belgian canals52 g
	kg and fine particles -50 mms70% whereas y1

Table 6

 6 Organic pollutant content (mgg ) in the sediment collected before dredging in the Seine basinin 1996, 1999 and 2000

		y1
	Site		HC tot PA H tot Ali tot PCB tot	Pesticides Toluene Phenols Reference
	Seine River, 1996-2000	n	61	38	33	20	15	15	20	This study
	(sediment)	d 10	21	3.4 -2	-0.005	0.91	0.2	1.5
		d 50	194	6.7	13	0.03	0.91	0.5	3.0
		d 90	794	20.5	54	1.3	0.91	1.5	4.6
		Min	3	1.4 -2	-0.005	0.91	0.2	1.1
		Max 1252	84	133	22.9	0.91	2.6	5
		Mean	302	10.9	23	1.4	0.91	0.8	3.0
		S.D.	330	13.9	27	5.2	-	0.7	2.8
		CV	109 127	118	367	-	91	90
	Seine River, 1995	Min		6	61	0.5				Meybeck et al., 1998
	(TSS)	Max		11	100	3
	North of France River	Mean		770						Ruban et al., 1998
	Louisiana waterways, USA Mean		7.3						Mowat and Bundy, 2001
	New Jersey, USA	Mean		17.4		0.6				Pollice et al., 1996
	Rhine River, Germany	Mean		2.6		5.5				Van Der Hurk et al., 1997
	Detroit River, USA	Mean		76.8		2.5				Besser et al., 1996
			50			10	90

Number of samples (n), median (d ), first and last decile (d , d ), minimum and maximum (min, max), standard deviation

Table

  Metal and organic micropollutant content (mgg ) in the leachates of the sediments sampledin 1996, 1999 and 2000

						y1
	Code Y a	As	Cd	Cr	Cu	Hg	Ni	Pb	Zn	Al	Fe	Mn	HC tot PA H b tot	Ali c tot
	V03	0.126 -0.02 -0.1	2.5 -0.005 -0.1 -0.1	6.5				-1	0.016
	V07		-0.02 -0.1 -0.1 -0.005 -0.1 -0.1	1.4				-1
	V08		-0.02 -0.1 -0.1 -0.005 -0.1 -0.1	0.7
	V10	0.09 -0.02 -0.1	1.6 -0.005 -0.1 -0.1	1.3
	V32	0.01 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1	0.3
	V33	0.02 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1	0.4
	V34	0.35 -0.02 -0.1 -0.1	0.06 -0.1 -0.1	3.9
	V35	0.15 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1	1.4
	V36	0.06 -0.02 -0.1 -0.1 -0.005 -0.1 -0.1	0.9
	V37	0.02 -0.02 -0.1 -0.1	0.14 -0.1 -0.1 -0.1
	V38	0.02 -0.02 -0.1 -0.1	0.02 -0.1 -0.1	0.6
	S1	-0.05 -0.02		-0.1 -0.005 -0.1 -0.1 -0.1 -1	0.1	0.1		-0.01 -0.02
	S2	-0.05 -0.02		-0.1 -0.005 -0.1 -0.1	0.1	0.2	0.2	0.1		-0.01 -0.02
	S3	-0.05 -0.02		-0.1	0.01 -0.1 -0.1 -0.1 -1	-0.1 -0.1		-0.01 -0.02
	S4	-0.05 -0.02		-0.1	0.009 -0.1 -0.1 -0.1 -1	-0.1 -0.1		-0.01 -0.02
	S5	-0.05 -0.02		-0.1	0.009 -0.1 -0.1 -0.1 -1	0.2	0.1		-0.01 -0.02
	S6	-0.05 -0.02		-0.1	0.009 -0.1 -0.1	0.2 -1	0.4 -0.1		-0.01 -0.02
	S7	-0.05 -0.02		-0.1	0

Table 7 (

 7 Continued)

	Code Y a	As	Cd	Cr	Cu	Hg	Ni	Pb	Zn	Al	Fe	Mn	HC tot

Table 8

 8 Metal and organic micropollutant content (mgl ) in porewaters of sediments sampledin 1996, 1999 and 2000

						y1
	Code Y a	As	Cd	Cr	Cu	Hg	Ni	Pb	Zn	Al	Fe	Mn	HC tot PA H tot Ali tot
	S1	-5	-21 0 -0.5	-10 -10	40 -10	168 1910	0.18 -20
	S2	8.5 -2		-10 -0.5	-10 -10	40	20	310 6970	0.2	40
	S3	8.6 -2		-10	0.73 -10 -10	30 -10	186 2350	-0.01 -20
	S4	-5	-2		-10	0.79 -10 -10	20 -10	215 5350	-0.01 -20
	S5	-5	-2		-10	0.69 -10 -10	20 -10	299 5670	-0.01	20
	S6	-5	-2		-10	0.74 -10 -10	30 -10	300	560	0.35 -20
	S7	10.8 -2		-10	1.06 -10 -10	10	10 1010	552	0.22	40
	S8	-5	-2		-10	0.5	-10 -10	50 -10	665 2950	0.27 -20
	S9	5.6 -2		-10	0.83 -10 -10 -10 -10	282 5620	-0.01 -20
	V1	9.4 -2 -10 -10 -0.5	26 -10	20				-50
	V2	5.8 -2 -10 -10 -0.5	25 -10	20				-50
	V3	-5	-2 -10 -10	0.73 -10 -10	10				x
	V4	6.6 -2 -10	20 -0.5	-10 -10	30				-50
	V5	-5	-2 -10 -10 -0.5	14 -10	20				-50
	V6	-5	-2 -10 -10 -0.5	17 -10	20				-50
	V7	-5	-2 -10 -10 -0.5	13 -10	20				-50
	V8	-5	-2 -10 -10 -0.5	26 -10	20				190
	O1	15.1 -2		-10	0.76	11 -10	40 -10	309 1230	-0.01 -20
	O2	11.8 -2		-10	0.7	-10 -10	30 -10	524	477	-0.01 -20
	O3	-5	-2		-10	0.66 -10 -10 -10 -10	170	521	-0.01 -20
	O4	-5	-2		-10	0.65	211 -10	40 -10	634	610	-0.01 -20
	O5	-5	-2		-10	0.76 -10 -10	20 -10	309	935	-0.01 -20
	O6	-5	-2		-10 -0.5	-10 -10	40 -10	191	423	-0.01 -20
	O7	-5	-2		-10 -0.5	-10 -10	40	20 1600	358	0.1	-20
	O8	-5	-2		-10 -0.5	-10 -10	30	10 1500	283	0.1	-20
	O9	-5	-2		-10 -0.5	-10 -10	30 -10	204	214	-0.01 -20
	S10												-50
	S11
	S12												80
	S13
	S14												120
	S15												-50
	S16												60
	O10												-50
	O11												-50
	O12												-50
	O13												-50
	O14												-50
	O15												-50
	O16												-50
	O17												-50
	See Fig. 1 for sampling site location.
	Year of collection.

Table 9

 9 Correlation matrix of analysed parameters for sediment samples of the Seine basinfrom 1996, 1999 and 2000

		TOC	Density Humidity OM	Fine	HC tot PAH tot Ali tot	PCB tot Toluene As	Cd	Cr	Cu Hg	Ni	Pb	Zn Al	Fe	Mn
						particles
	TOC	1
	Density	I0.70	1
	Humidity	0.44 I0.86	1
	OM	0.36 y0.77	0.69	1
	Fine particles y0.03 I0.56	0.53	0.51	1
	HC tot	0.58 I0.60	0.68	0.63	0.36	1
	PA H tot	0.16	0.11 y0.10	y0.17 y0.27	0.07	1
	Ali tot	0.20	0.29	0.26	y0.32 y0.38	y0.19	0.29	1
	PCB tot	0.34 y0.17	0.22	y0.35 y0.11	0.07 y0.04 y0.24	1
	Toluene	0.54 y0.43	0.59	0.59	0.38	0.58 y0.18 y0.26	0.21 1
	As	0.22 I0.68	0.40	0.81	0.71	0.70 y0.17 I0.52 y0.14 0.60	1
	Cd	0.59 y0.13	0.17	0.20	0.00	0.20	0.24	0.39 y0.05 0.54	0.05	1
	Cr	0.47 I0.66	0.77	0.73	0.66	0.60 y0.05 y0.03	0.11 0.45	0.64	0.37	1
	Cu	0.62 I0.51	0.51	0.47	0.28	0.62	0.13 y0.02	0.50 0.75	0.39	0.47	0.71 1
	Hg	0.27	0.18 y0.02	y0.07 y0.17	y0.07	0.23	0.04	0.19 0.67	y0.13	0.27 y0.06 0.23	1
	Ni	0.48 y0.62	0.77	0.77	0.47	0.61 y0.13	0.00	0.11 0.58	0.60	0.38	0.91 0.51	0.07 1
	Pb	0.32 y0.20	0.21	0.14 y0.12	0.34	0.16	0.19	0.47 0.75	0.01	0.48	0.25 0.61	0.30 0.17	1
	Zn	0.50 y0.58	0.59	0.54	0.30	0.63	0.08	0.05	0.49 0.65	0.40	0.56	0.78 0.89	0.18 0.63	0.75 1
	Al	0.26 y0.62	0.37	0.82	0.76	0.78 y0.24 I0.47	0.45 0.48	0.94 y0.01	0.86 0.51 y0.16 0.62	0.02 0.52 1
	Fe	0.12 y0.40	0.37	0.75	0.80	0.57 y0.35 I0.49	0.24 0.36	0.91 y0.06	0.83 0.34 y0.13 0.63 y0.16 0.37 0.89 1
	Mn	0.13 y0.44	0.07	0.83	0.68	0.74 y0.21 I0.59	0.39 0.60	0.92 y0.05	0.86 0.43 y0.14 0.40 y0.05 0.43 0.84 0.83 1
	n)15. The highly significant (P-0.01) correlations are indicated in bold.

Acknowledgments

The authors would like to thank the teams of the Service de Navigation de la Seine (SNS), Voies Navigables de France (VNF) and Entreprise