Urtzi Ayesta

Lionel Bertaux

Denis Carvin

Non-Intrusive Scheduling of TCP Flows

come   L'archive ouverte pluridisciplinaire

Introduction

The last twenty years have witnessed a tremendous effort to understand and optimize the performance of congestion control algorithms over the Internet. Many variants of TCP have been proposed and studied, and the interaction of congestion control and buffer dynamics have also thoroughly been investigated. Without this list being exhaustive, researchers have looked at ways to improve the performance of TCP by modifying various aspects of the Additive Increase Multiplicative Decrease behavior of TCP, or by modifying the way packets are handled in buffers. An important stream of research, promoted by the advocates of the diffserv architecture, has been to look at how to improve the quality of experience by implementing service differentiation and priorities in the routers, see [START_REF] Blake | An architecture for differentiated services[END_REF]. Several works have shown that the implementation in routers of scheduling policies can improve the performance, particularly in the case of overload or close-tosaturation regimes, see for instance [START_REF] Schroeder | Web servers under overload: How scheduling can help[END_REF] and [START_REF] Biersack | Scheduling in practice[END_REF].

In spite of all these efforts, the actual number of changes and modifications that have been implemented in real protocols and systems is rather small. The main reason for this is that even though such proposals definitely improve the efficiency locally, there is little understanding as to what would be the impact if they were implemented globally at the scale of the Internet. An argument against the deployment of scheduling disciplines in routers is presented in [START_REF] Verloop | Stability of size-based scheduling disciplines in resource-sharing networks[END_REF], where the authors show that the performance in a network where each node implements a size-based scheduling can be extremely poor.

The above provides us with the motivation to undertake a different approach. We focus on a pair of origin and destination nodes, and we develop a scheme to implement scheduling policies on TCP flows in a non-intrusive and transparent way with respect to the rest of the network. In other words, the TCP segments of a given origin-destination are scheduled -according to some policy that can be freely chosen -without modifying the bandwidth share assigned by the network to this particular set of flows. This permits to build new schedulers that improve the performance for a set of flows sharing the same origin-destination pair, without having any harmful impact on the rest of the flows being transmitted over the Internet.

We now mention the main contributions of this paper. In the first main contribution we develop gtcp, a general congestion-control algorithm that can interchange the contents of segments from the flows within a given origin-destination pair in a non-intrusive way, that is, without modifying the bandwidth-share assigned to this set of flows. We also establish that having an infinite sender's and receiver's buffer is sufficient and necessary in order for gtcp to be non-intrusive. In the second main contribution, we apply classical results from scheduling theory to show that in the absence of packet losses and packet reordering, scheduling disciplines that favor TCP flows based on the unsent amount of data or data already sent minimize the transfer time and the number of on-going flows. We also develop FAIR, a scheduler that reduces the transfer time of each flow when there is no packet loss nor packet reordering on the network path. In our third main contribution we develop SCHED TCP, a user space implementation of our scheme in order to evaluate its performance on the Internet. Our experiments illustrate the non-intrusive property of SCHED TCP, and also illustrate that the performance gain with SCHED TCP can be considerable. Our scheme is scalable, and it could be incrementally deployed on the Internet improving the user experience on every origin-destination pair.

It is important to highlight that all the above positive and beneficial results do not inflict any harm to the rest of the network, and that gtcp and SCHED TCP can work with any TCP version like New Reno [START_REF] Floyd | The newreno modification to TCP's fast recovery algorithm[END_REF], CUBIC [START_REF] Ha | CUBIC: a new TCP-friendly high-speed TCP variant[END_REF] or Compound [START_REF] Tan | A Compound TCP approach for high-speed and long distance networks[END_REF]. These two aspects would permit an incremental deployment of SCHED TCP over the entire Internet improving the performance of flows on every origin-destination pair. The main application domain of our approach correspond to situations in which there are many TCP concurrent connections within the same origin-destination pair, for instance this might happen as a consequence of HTTP 1.1 [START_REF] Fielding | Hypertext transfer protocol[END_REF], Web 2.0 applications using AJAX (Google Maps etc.) [START_REF] Schneider | The new web: Characterizing ajax traffic[END_REF], Split TCP [START_REF] Border | Performance enhancing proxies intended to mitigate link-related degradations[END_REF], Parallel Sockets [START_REF] Sivakumar | Psockets: The case for application-level network striping for data intensive applications using high speed wide area networks[END_REF], and also with the use of ChromeBook's [START_REF]Chromebook[END_REF] where the user accesses to all services through the same back-end server infrastructure.

Our work shares similarities with the approaches of [START_REF] Rai | LAS scheduling approach to avoid bandwidth hogging in heterogeneous TCP networks[END_REF][START_REF] Avrachenkov | Differentiation between short and long TCP flows: Predictability of the response time[END_REF][START_REF] Schroeder | Web servers under overload: How scheduling can help[END_REF][START_REF] Chowdhury | Managing data transfers in computer clusters with orchestra[END_REF], but there are two main differences. The first one is that our approach ensures that the bandwidth share taken by an origin-destination pair remains unmodified with respect to what would happen under standard TCP, and the second one is that we do not necessarily require implementing a size-based scheduling policy. In our approach the congestion-control and scheduling features of TCP are decoupled, and for any origin-destination pair we are free to choose how flows are scheduled. Size-based scheduling is an appealing option since it enables to derive mathematical properties of the approach. However, other solutions are also equally viable, like giving priority to real-time, multimedia or interactive traffic over best-effort one, or by following an arbitrary order that would be optimized by the application layer.

The rest of the paper is organized as follows. In Section 2 we provide a brief overview of the related literature, in Section 3 we develop gtcp and in Section 4 we show how classical results from scheduling theory can be used to improve the performance of TCP flows. In Section 5 we present a discussion on the technical conditions needed to be non-intrusive, and Section 6 presents the results we have obtained with SCHED TCP.

Related work

There are two main research bodies that are related to our proposal, one deals with modification and improvements of the TCP stack, and the other with the implementation of scheduling policies in IP networks. We briefly review some of the main results in these two areas.

The number of TCP modifications that have been proposed over the years is huge. Without aiming at being exhaustive, we mention some of the most significative ones: modification of the initial window [START_REF] Allman | Increasing TCP's initial window[END_REF], faster start proposals [START_REF] Padmanabhan | TCP fast start: A technique for speed-ing up web transfers[END_REF], handling more efficiently packets losses as done with ECN [START_REF] Ramakrishnan | The Addition of Explicit Congestion Notification (ECN) to IP[END_REF][START_REF] Floyd | TCP and explicit congestion notification[END_REF], SACK [START_REF] Floyd | An extension to the selective acknowledgement (sack) option for tcp[END_REF] or RCP [START_REF] Dukkipati | Proportional rate reduction for TCP[END_REF], or improving the estimation of the available bandwidth as done with TCP Westwood [START_REF] Saverio | TCP westwood: Bandwidth estimation for enhanced transport over wireless links[END_REF]. There have been dozens of new TCP proposed, and current Linux implementations deploy TCP CUBIC [START_REF] Ha | CUBIC: a new TCP-friendly high-speed TCP variant[END_REF] whereas Windows implements TCP Compound [START_REF] Tan | A Compound TCP approach for high-speed and long distance networks[END_REF]. These TCP versions only modify the congestion algorithm, but do not add new functionalities. Modern approach to Transport protocol design requires to split Transport layer [START_REF] Ford | Breaking up the transport logjam[END_REF] into sub-layers that can be shared between applications or between connexions. This approach has been followed by MPTCP [START_REF] Handley | TCP extensions for multipath operation with multiple addresses[END_REF] which enables to enhance available bandwidth by using all the network interfaces and paths between two hosts.

The diffserv architecture was described in [START_REF] Blake | An architecture for differentiated services[END_REF], here each packet is classified into a limited number of traffic classes and each router on the network is configured to differentiate traffic based on its class. An example is [START_REF] Noureddine | Improving the performance of interactive TCP applications using service differentiation[END_REF] where interactive traffic is given priority over the rest. In order to preserve the quality of service, researchers have also advocated other solutions like admission control [START_REF] Massoulié | Arguments in favour of admission control for tcp flows[END_REF] or active queue management [START_REF] Adams | Active queue management: A survey[END_REF]. Authors of [START_REF] Chowdhury | Managing data transfers in computer clusters with orchestra[END_REF] have considered the scheduling of application traffic in computer clusters. Another stream of works have investigated the impact of giving priority in buffers to packets based on the size of the flows [START_REF] Rai | LAS scheduling approach to avoid bandwidth hogging in heterogeneous TCP networks[END_REF], [START_REF] Avrachenkov | Differentiation between short and long TCP flows: Predictability of the response time[END_REF] and [START_REF] Schroeder | Web servers under overload: How scheduling can help[END_REF]. The latter works draw from classical scheduling theory that giving preference to short tasks is beneficial in a single-server queue. Well-known results are that among size-aware policies, Shortest-Remaining Processing Time (SRPT) minimizes the number of tasks in the system [START_REF] Schrage | A proof of the optimality of the shortest remaining processing time discipline[END_REF], and that among sizeunaware policies Least Attained Service (LAS) minimizes stochastically the number of tasks in the system when the service time distribution has a decreasing hazard-rate (DHR), see [START_REF] Righter | Scheduling multiclass single server queueing systems to stochastically maximize the number of successful departures[END_REF]. We refer to [START_REF] Weiss | A tutorial in stochastic scheduling[END_REF] for a survey with the most important scheduling results.

3 Non-intrusive scheduled TCP: decoupling of congestion control and scheduling

In this section, we show that it is possible to schedule the segments of a set of application flows sharing the same origin-destination route, without modifying the bandwidth share that would have been perceived using a standard TCP implementation. In the ensuing we will use the term tcp to refer to a standard TCP implementation, regardless of the specific TCP version. In other words, if V tcp (t) denotes the amount of traffic that has been injected in a given route by TCP up to time t, we will show that under the condition that the sender and receiver buffers are unbounded, a more general congestion-control gtcp can arbitrarily interchange the contents of the segments using a policy π, in such a way that V gtcpπ (t) = V tcp (t), ∀t. The latter property implies that gtcp is non-intrusive with respect to the reference protocol tcp. This opens up the path to optimize the quality of service perceived by this set of flows, without incurring any harm on the other flows sharing the network. To build such a non-intrusive gtcp, we will need to be able to emulate at all times what would have been the state of every flows under tcp. In turn, this would enable gtcp to inject segments into the network at the exact same times as what tcp would have done. We note that naive solutions like combining all TCP flows into one single flow do not allow to achieve this goal.

In order for gtcp to be able to implement an arbitrary scheduling policy π, gtcp will need to keep two separate state representations for every flows: the virtual that keeps track of the state under tcp and the real one. Every time a packet is going to be sent (which depends on the virtual states), the scheduler π will choose which flow will really send its contents (this can depend on both the real and virtual states, and on other contextual information such as the QoS). In order to achieve our goal, we will show that is sufficient for gtcp, to encapsulate in all its segments, information on both the virtual TCP flow (which enables to keep track of the state of every virtual TCP flow) and on the real TCP (which enables to update the real state).

The rest of the section is as follows. In Subsection 3.1 we describe how a non-intrusive gtcp can be built for any scheduling policy π by describing in detail the algorithms that deal with the main events in a network, namely, arrival of application data (wri), reception of acknowledgement (ack), and retransmission timeout (rto). In Subsection 3.2 we state the formal result, establishing that if the sender and receiver's buffers are unbounded, it is possible to implement any scheduling policy π such that V gtcp (t) = V tcp (t), ∀t.

Algorithmic framework : maintaining virtual queues

As depicted in the upper plane of Figure 1, TCP can be modeled as a multiple-server multiplequeue system, where each server is associated to a transmission queue (or queue). Our approach decouples queues and servers with a scheduling policy π and guarantees that servers' activities remain the same. In our convention, a service (or a sequence number) is the transmission of a segment, it starts with the first transmission attempt and is completed on the reception of its ack. The service can be preempted upon reception of three duplicate ack's, which will trigger π to choose a packet (not necessarily the same) for transmission. As a result, a server offers services in parallel, whose duration and order of completion depend on the network and on tcp. The total amount of traffic produced by the servers is captured by the function V tcp (t).

Pending Segment

tcp gtcp V i q i i a -s i q V (t) tcp V (t) gtcp In-Flight Segment Figure 1:
The two planes of gtcp. While in the underlying plane the second queue is prioritized, we maintain in the upper plane the virtual states of queues.

We consider an established state without any optional behavior. For the sake of clarity, we assume the size l of arrivals in queues to be multiples of the maximum segment size mss. As a consequence all the packets have the maximum segment size. This assumption is not really required in order to build gtcp, but it greatly simplifies the exposition, see Remark 1 for a discussion on how to handle variable segment sizes.

In tcp, the possibility for server i to transmit a new segment depends on its state variables which are :

• q i : Size of transmission of queue i

• s i : Highest in-flight sequence number

• a i : Highest cumulatively acknowledged sequence number

• cwnd i : Size of congestion window • rwnd i : Size of receiver window (remote host)
In order to be standard compliant [START_REF] Allman | TCP congestion control[END_REF], a new segment cannot be sent by server i if cr i = 0 or q i = 0. Here, cr i denotes the transmission credit and is expressed as

cr i = min(cwnd i , rwnd i ) + a i -s i .
With gtcp, we decouple queues from servers, as a consequence q i will depend on π. As a substitute for q i , we introduce q v i , the virtual size of queue i which keeps track of the value of q i under tcp. Server i evaluates its state to offer new services on the occurrence of events which are either (i) wri l i : l bytes arrive to queue i or (ii) ack s,s i,j : segment s of queue j is acknowledged with the service s of server i. Algorithm 1 details the actions to perform on the occurrence of the event wri l i .

On the arrival of l data in queue i (recall that l is proportional to mss), server i updates the size of its virtual queue q v i to compensate the arrival in its real queue q i , and it offers new services up to its limitation based on its virtual queue. After each service, server i updates its Algorithm 1 on wri(i, l)

q v i ⇐ q v i + l // q i ⇐ q i + l while cr i > 0 and q v i > 0 do serve(i, s i ) s i ⇐ s i + mss // cr i ⇐ cr i -mss q v
i ⇐ q v i -mss // q j ⇐ q j -mss end while state as follows: it increments its sequence number (which decreases its transmission credit), and decrements the size of its virtual queue q v i . The latter means that server i virtually dequeues the data from queue i and consider that the served queue is virtually unchanged. The actions undertaken in the case where server i offers service s are given in pseudo-code in Algorithm 2.

Algorithm 2 serve(i, s) j, s ⇐ schedule() // implements π P s,s i,j ⇐ tcp head(i, s) | sched head(j, s ) | data() send(P s,s i,j ) // generate sen s,s i,j

set timer(P s,s i,j ) // schedule rto s i associate((i, s), (j, s )) mark(j, s )

When server i is about to transmit a segment s, it first asks to the external function schedule which segment s of which queue j it must serve. The function schedule implements the scheduling policy π specified by gtcp. Then server i builds a packet containing the service identification (i, s), the data identification (j, s ) and the data. Both identifiers are associated and the segment of data is marked as in-flight for the scheduler. We denote the transmission event by sen s,s i,j . Note here that policy tcp is the particular case of gtcp when the scheduler π assigns (j, s ) = (i, s).

On the receiver side, the counterpart of event sen s,s i,j is rcv s,s i,j . When this event takes place, the receiver produces the acknowledgement event ack s,s i,j and advertises rwnd i . Additionally, it keeps the association (i, s) and (j, s ). In the case of multiple reception of the same service (acknowledgment loss, poor RTT estimation. . . ), the same association is immediately acknowledged. As we explained above, an ack s,s i,j event can trigger the transmission of a packet by server i. The reaction to this event is described in Algorithm 3.

On the reception of an ack, server i updates its congestion state. In particular, server i modifies the value of cwnd i , rwnd i , a i (and consequently cr i ) but also performs other actions like timers' cancelation, RTT estimation, etc. Since these actions depend on the version of TCP, we encapsulate them in the up cong state function which returns the acknowledgement type (number of duplication). If the acknowledgement is a third duplicate, a retransmission is triggered, which means that the service is preempted. Thus, we can serve another application and associate an additional segment to this service. If the acknowledgement is not a third duplicate, new services are offered with the serve function. In the case of a cumulative acknowledgement, the acknowledged segment of queue is released. All the other segments that were associated to the service are Algorithm 3 on ack(i, s, j, s ) ack type ⇐ up cong state() if ack type = third dupack then serve(i, s) else if ack type = cumulack then unmark all associations of((i, s)) remove all associations((i, s)) free tx buf((j, s )) end if while cr i > 0 and

q v i > 0 do serve(i, s i ) s i ⇐ s i + mss // cr i ⇐ cr i -mss q v
i ⇐ q v i -mss // q j ⇐ q j -mss end while end if unmarked and will be reconsidered by the scheduler for future transmission.

Finally, we have the rto s i event, which is a retransmission time-out. This even is processed by the sender like the detection of a third duplicate acknowledgement.

Formal statement

Based on this algorithmic framework, we have: Proposition 1 In any given sample-path, it is possible to adopt any arbitrary scheduling policy π such that ∀t, V gtcp (t) = V tcp (t) if and only if the sender and receiver buffers are not bounded.

Proof. Let T tcp (t) = {t i ∈ [-∞, t[ i ∈ N}
denote the set of event times up to time t under the standard tcp, with the convention that ∀p < q, t p ≤ t q . Equivalently let T gtcp (t) denote te set of event times with gtcp. To specify which event occurs at these instants, we define a function E tcp : T tcp (t) → E tcp , where E tcp is the set of possible events that can occur at time t. The function E gtcp is defined equivalently. To define E gtcp we only consider the events that impact TCP's behavior, namely, E gtcp = {wri l j , ack s,s i,j , rto s i , sen s,s i,j , dat s,s i,j } where i, j are a queue and server identifier at time t, respectively, and l, s, s ∈ N 3 . E tcp is the same as E gtcp with the restriction that necessarily s = s and i = j. It is easy to see that we have:

V gtcp (t) = |{t ∈ T gtcp (t) | ∃(i, s), (j, s ) s.t. E gtcp (t ) = sen s,s
i,j }| × mss, which states that the total amount of traffic injected up to time t equals the number of segments sent before t multiplied by their size. V tcp (t) is similarly defined.

By construction of Algorithms 1-3, for any policy π of gtcp, we have T gtcp (t) = T tcp (t), and the following equivalence:

(∃ (i, s) | E tcp (t ) = sen s i ) ⇐⇒ (∃ (i, s), (j, s ) | E gtcp (t ) = sen s,s i,j ).
As a result, we have V gtcp (t) = V tcp (t), ∀t, regardless of the policy π implemented by gtcp. For the above argument to hold the sender and receiver buffers must be infinite. If the sender buffer were finite, it is possible to find a sequence of TCP flows arrivals, such that under π the buffer overflows and segments are lost, whereas the virtual buffer remains small. The latter can happen on the sender's side for a low priority queue which is significantly less served than under tcp. On the receiver's side, it can happen for a priority queue which delivers a much larger amount of data than under tcp, the receiver window becoming possibly less than the congestion window. Such events will alter the future events in such a manner that their corresponding algorithm can not be called and it is no longer possible to preserve T gtcp (t) = T tcp (t) from that moment on.

Remark 1 (On arrivals that are not a multiple of mss) In this case we could encounter the situation where the size of a service is greater than the size of the prioritized queue. We would thus need to encapsulate several segments of different queues in the same service. The price of this situation is that it requires an enhanced mechanism to associate one service to a set (or several sets if retransmission) of queue segments that have different sizes.

The unboundedness of the buffers is needed in order for gtcp to be non-intrusive, but is not required to implement an arbitrary scheduler in reality. This is investigated in Section 6, where we will show that SCHED TCP, a user space implementation of gtcp, is qualitatively non-intrusive, (i.e. at a coarser time-scale than the one of the packet).

Scheduling: optimality of size-based policies

In Section 3 we have shown that the congestion control and scheduling aspects of TCP can be totally decoupled. As a consequence, a source can efficiently schedule TCP segments without any harmful impact on any other active data transmission in the network. The properties of the scheduling algorithm were hidden behind the function schedule used in Algorithms 2.

The objective of this section is to elaborate on how size-based scheduling and priority policies can improve the performance perceived by flows using the same origin-destination pair. In particular, we will discuss how these disciplines can reduce the transfer time of flows and also the number of on-going flows. Throughout this section we assume that all the data of a given flow is available to be scheduled. If an application transmits data over the same TCP connection at discontinuous time intervals, for the purposes of this section each of these transmissions can be seen as a separate flow.

Equivalence with a queue with time-varying capacity

Our scheduling problem is different from the classical problem studied in the literature. In the classical problem, tasks receive reliable service "instantaneously" and depart as soon as their required service time has been served, whereas in our setting, segments are scheduled on transmission epochs, and a while later, when the ack is received, we consider the information to be successfully transmitted.

In order to establish optimality results, we need to assume the absence of segment losses, and also of segment reordering. The results of Section 6 indicate that, in the presence of segment losses and segment reordering, size-based scheduling will still provide a significant performance gain, see also Remark 2. Since neither data segments nor ack's are reordered, we can equivalently assume that a segment is successfully transmitted as soon as it departs from the sender's buffer, and we can thus say that a flow departs the system as soon as its last data segment is sent. Let N π (t) denote the set of flows that have unsent segments at time t and let N π (t) = |N π (t)| denote the number of flows present at time t. The assumption that segments are neither lost nor reordered directly implies that minimizing N π (t) is equivalent to minimizing the number of active flows measured at the reception of ack's.

C(t) t V (t) [#mss]
As explained in Section 3, our scheme enables that the total number of transmitted segments at time t, V gtcp (t), is independent of how segments are scheduled by the scheduler π implemented in gtcp. Let t i , i = 1, 2, . . . , denote the transmission epoch of the i-th segment under tcp. It will be proven useful to consider a capacity function C(t) = mss × i:t i ≤t δ(t -t i ), where δ(•) is the Dirac delta function. Figure 2 depicts the function C(t) in a particular example. The function C(t) can be seen as time-varying capacity function, and it captures the instantaneous rate at which data is being transmitted, that is, at time t data is instantaneously transmitted at rate C(t). It is easy to see that for all t, t -∞ C(s)ds = V tcp (t), so under the function C(t), a segment is instantaneously transmitted at times t i , i = 1, 2, . . . ,.

The problem of determining an optimal scheduling algorithm π can now be cast as a problem of optimal scheduling in a single-server queue with a time-varying service capacity C(t). As we will show in Subsection 4.3, this allows us to use known results from the literature to establish optimality results. Note that we have dropped the dependency of C(t) on π to highlight that, as shown in Proposition 1, we can implement a scheduler π while preserving the bandwidth share at all time epochs, i.e., V gtcp (t) = V tcp (t), ∀t. This result is critical in order to compare the performance of scheduling disciplines. We will now introduce the main size-based disciplines that we will need in the rest of the section.

Scheduling disciplines

The discipline implemented by gtcp, denoted by π, specifies which flow is served at time t. A selected flow will receive instantaneous service at rate C(t). Since C(t) is formed by Dirac delta functions, this implies that if t = t i , then the rate is 0, and that if t = t i , a segment with mss amount of data will be sent. Depending on the information available to the scheduler, two important classes of disciplines are: (i) size-aware if the required service times of flows is known and (ii) age-based if the amount of received service is known (but not the required service time). The notions of required service time and received service commonly used in the scheduling literature must be here understood as amount of segments a flow must transmit and amount of segments already transmitted by a flow, respectively. Well-known disciplines are:

• Least Attained Service (LAS) is an age-based discipline which serves the flow that has received the least amount of service, which as explained above, in our terminology means the TCP flow that has transmitted the least number of segments.

• Shortest-Remaining-Processing-Time (SRPT) is a size-aware discipline that serves the flow with the smallest remaining service time.

• Fair TCP (FAIR) is a size-aware discipline, which serves the flow that will finish next under tcp.

(FAIR) is inspired by the Fair Sojourn Protocol introduced in [START_REF] Friedman | Fairness and efficiency in processor sharing protocols to minimize sojourn times[END_REF]. In the absence of segment losses and segment reordering, if the scheduler is size-aware, and if gtcp knows the behavior of tcp, it is possible for gtcp the scheduler to infer exactly which would be the next flow under tcp.

It will also be useful to consider priority policies that apply a priority among different type of flows. Here a type might refer for instance to the application: web, VoIP, P2P etc.

Optimality results

Proposition 2 below summarizes our main theoretical results that illustrate how size-based scheduling improves the performance of the flows in a given origin-destination pair. We will need the notion of hazard-rate. Let P(S = k) denote the probability that a flow requires to transmit k segments. The hazard rate of a distribution is then given by h(k) := P(S=k) P(S≥k) , and when h(k) decreases in k we say that the distribution is of type decreasing hazard rate (DHR). Flow size distributions on the Internet are commonly modeled with distributions of type DHR, see for example [START_REF] Crovella | A practical guide to heavy tails. chapter Heavytailed Probability Distributions in the World Wide Web[END_REF].

Proposition 2 Under the conditions of Proposition 1, if segments are neither lost nor reordered, we have:

• If the scheduler is SRPT, then {N SRPT (t)} t≥0 ≤ {N gtcp (t)} t≥0
, where gtcp can implement any arbitrary size-aware discipline.

• If the service time distribution is DHR, then P(N LAS (t) > k) ≤ P(N gtcp (t) > k), ∀k, where gtcp can implement any arbitrary age-based discipline.

• If the scheduler is FAIR, then T FAIR i ≤ T tcp i , where T i denotes the transfer time of the i-th flow.

• If flows are classified into types, then E(N µ-rule ) ≤ E(N gtcp ), where µ-rule denotes the priority discipline that gives full service to the type (present in the system) with smallest mean number of segments.

Proof. The proofs are applications of known results to the system with instantaneous transfer time C(t), see Appendix A for more details.

By a straightforward application of Little's Law, we then obtain the following corollary:

Corollary 1 SRPT, LAS, FAIR, µ-rule minimize the mean transfer time of flows in each of the settings described in Proposition 2.

Remark 2 (On the necessity of absence of segment losses and reordering) These assumptions are required to establish the optimality results of Proposition 2. To explain this, consider the case of SRPT and that at a given time there are two flows, one with R 1 (t) = 1 and the other one R 2 (t) = 2. SRPT will schedule flow 1, but if this segment is lost or reordered, flow 2 might receive the ack's earlier and as a consequence finish its transmission earlier. This would imply that SRPT is not optimal in the sample-path sense as stated in Proposition 2. For LAS we can construct similar counterexamples. Regarding FAIR, if there are losses or reordering it is not possible to predict exactly which flow will finish next. As a consequence, it will no longer hold that FAIR reduces the transmission time of all flows. Nevertheless, the results of Section 6 indicate that in the presence of segment reordering and losses, the performance gain of SRPT, LAS and FAIR with respect to tcp is considerable.

On the technical conditions

This section presents a discussion on the impact of various of the conditions mentioned in Propositions 1 and 2, namely, (i) schedulability of traffic, (ii) unbounded buffers, (iii) size of segments and (iv) absence of segment losses and reordering.

(i) Schedulability of traffic. The possibility to schedule transmission queues only arises when several queues sharing the same route are non-empty at the same time. In order to obtain an idea of the amount of traffic that satisfies this assumption, we have analyzed thirty minutes of TCP/IPv4 traffic captured from Seattle to Chicago in March 2014 on an OC192 backbone link of a Tier1 ISP [START_REF]The CAIDA UCSD anonymized internet traces[END_REF]. Since it is not possible to infer the state of a TCP transmission queue in the Internet, we approximate the number of non-empty queues by the number of active flows. A flow is considered active from the time of its first data segment until the time of its last one, and we say that two flows compete on a route if their activity period overlap. Table 1 summarizes our results, where we represent the number of routes that have competing flows, the total number of competing flows, and the total data volume carried by competing flows. The main conclusion is that even though only 18.1% of the flows compete, they carry 58.2% of the total data volume. This illustrates that, in addition to applications mentioned in the introduction, the transmission of big data files can be a domain of interest for our scheme, and in particular we can think of cloud deployment, database replication and distributed analysis as considered in [START_REF] Chowdhury | Managing data transfers in computer clusters with orchestra[END_REF].

(ii) Unbounded buffers. On the sender side, infinite buffers are only necessary for low priority queues and can be emulated by a blocking call on the corresponding socket. Thus, if low priority applications are able to wait like in the case of file transfers, we can consider that the sender buffer is infinite. On the receiver side, it is reasonable to consider that the buffer is infinite when congestion window is always less than the receiver window. The latter naturally happens when the congestion is in the network and not on the receiving host. For instance, the approach of [START_REF] Ravis | Socket buffer auto-sizing for high-performance data transfers[END_REF], in which the receiver's window is dynamically adjusted, would ensure that the receiver window is always larger than the congestion window.

(iii) Size of segments. In Remark 1 we explained that it was possible to handle different segment sizes at the price of adding a layer of complexity to our scheme. Using the publicly available statistics from CAIDA [START_REF]The web site of the cooperative association for internet data analysis (caida)[END_REF], in Figure 3 (iv) Absence of segment losses and reordering. These assumption was needed in order the optimality results of Proposition 2 to hold. In the presence of segments losses and reordering, it is not possible to prove any optimality result, but we nevertheless expect that gtcp can provide an important performance gain over tcp. We also note that if ECN [START_REF] Floyd | TCP and explicit congestion notification[END_REF] were deployed, the optimality results of Proposition 2 would hold even with losses. From the losses point of view, the worst-case scenario is the loss of the last ack for a flow. In such a case, a server would detect the loss with the rto event and all the data sent up to this event would not have been from a priority flow.

Implementation and Experimental Results

We present an implementation of gtcp along with experimental results for different scheduling policies.

SCHED TCP, an implementation of gtcp

A congestion control algorithm can be implemented either by relying on an existing Transport protocol or by deploying a new one (as a version of TCP for example). From an implementation point of view, the easiest way to obtain a congestion control gtcp that mimics Algorithm 1 of Section 3 is to maintain as many active connections as tcp would have, letting each of these connections use tcp congestion control. In turn, the latter guarantees that we can replicate the event generation of tcp, and we can thus obtain V gtcp (t) = V tcp (t), ∀t. The shared scheduling layer of gtcp can be deployed on top of these tcp connections as an intermediate layer between applications and connections. This approach follows the current trend in Transport protocol design [START_REF] Ford | Breaking up the transport logjam[END_REF], which we already mentioned in Section 2. The implementation of gtcp used for experiments is a scheduling layer between applications and legacy TCP connections illustrated by Figure 4. This user space program is coded in C on Linux 3.2 and referred to as SCHED TCP.

App App

SCHED TCP distributes application flows among TCP connections at the sender side and rearranges them at the receiver's side. The scheduling component π is in charge of selecting the prioritized flow, while the main component encapsulates data in a scheduling header that identifies the selected flow and forward them to TCP. Algorithm 4 is an implemented solution inspired from Algorithm 1 and 2, where the schedule function refers to the scheduling policy π being implemented. When a TCP connection is ready to accept new data in its sending buffer, it checks the state of its virtual queue and chooses the highest priority data flow depending on the scheduling policy π. In the state depicted by Figure 4, the connection T CP 1 has space in its sending buffer and is thus ready to accept new data coming from the application chosen by the scheduling policy π. The schedule function of Algorithm 4 implements tcp, SRPT, LAS and FAIR policies described in Section 4.3.

Algorithm 4 On connection ready(i)

if q v i > 0 then j, s ⇐ schedule() // implements π P s j ⇐ sched head(j, s ) | data() enqueue(i,P s j ) // equivalent to sen s,s i,j

q v i ⇐ q v i -mss // q j ⇐ q j -mss end if
Compared to the theoretical behavior of gtcp, SCHED TCP has some limitations due to the use of legacy TCP connections. Since transmission credit is managed by TCP, it is not possible to preempt a low priority segment once it has been queued in the socket i.-e. parts of transmission buffers are not shared among flows. More specifically, the scheduling discipline π of SCHED TCP can choose the amount of data given to TCP connections while gtcp allows to choose the exact segment sent on the network. Despite this difference, the following section shows that SCHED TCP provides a significant performance gain over tcp.

Experimental Results and comparison of policies

In this sub-section we present measurements done on a real network with SCHED TCP deployed on a origin-destination pair consisting of two desktop computers (see Figure 5). The origin is located in our research lab and the destination is in a home network with poor Internet connection (bandwidth equivalent to 350kBps). We note that in a real network is impossible to compare the performance of two protocols under the same traffic conditions. In order to counteract the non-replicability of the experiments, we repeat each experiment 100 times and then take an average.

Internet Client Server

Lab Gateway ISP Gateway Non-intrusiveness. In Figure 6 we depict the average throughput of flows for tcp and SRPT policies. We generate three flows at predefined starting times and as explained above, we repeat the experiment 100 times. In the top figure all three flows are handled by tcp, whereas in the figure below SCHED TCP handles the flows long and short, and tcp handles the flow sample. Upon arrival at t = 5s, SCHED TCP gives full priority to short, and as a consequence short finishes its transmission around t = 11s. On the other hand, long finishes its transmission at around t = 25s in both cases. The throughput obtained by sample at any time is similar in both cases, which illustrates the non-intrusiveness of SCHED TCP. Performance of size-based disciplines. In order to compare the performance of the scheduling policies of Section 4.3, we now consider a more realistic traffic scenario experimented on the production network of our lab (still a real network, but less bandwidth limitations). New flows are generated according to a Poisson process of rate λ. The flow size is assumed to follow a Pareto distribution, that is, if S denotes the size of a flow, we consider that P(S > x) = 1 (1+cx) α , ∀x ≥ 0. Pareto distribution is of DHR type, and has been commonly used to describe the file size distribution on the Internet. We set α = 3 and c = 10 -7 , which gives an average file size E(S) = 5M B. The capacity of the link is C = 12M Bps, and the segment size 1448B. The value of λ is obtained by fixing the overall load in the system to 0.9, that is, λE(S)•1448 C = 0.9. The results we report come from 100 independent experiments.

Figure 7 shows the distribution of the number of active connections. We observe that SRPT and FAIR minimize the number of active connections, and that even though LAS is better than tcp, its performance is worse that than SRPT and FAIR. The latter shows that the fact of being size-aware, gives a significant advantage to both SRPT and FAIR.

Figure 8 shows the distribution of transfer time per flow. As in the case of the number of connections, size-aware policies SRPT and FAIR provide a significant performance gain. It is noteworthy to mention that SRPT and FAIR outperform LAS and tcp regardless of the file transfer duration. We also see that LAS improves the transfer time of short flows. However, for flows that last more than 6 seconds, LAS is less efficient than tcp. This is expected since LAS gives priority to new flows at the expense of older ones.

In Figure 9 we depict the transfer time for every simulated flow. A dot in (x, y) means that a flow of size x has finished its transfer at time y. We observe that as the flow size increases, the dispersion of the transfer time increases under LAS and tcp, and that the dispersion stays much smaller under SRPT and FAIR. This means that size-aware are not only better in terms of transfer time, but that they also increase the predictability of the performance, that is, all flows of the same size will have a similar transfer time.

Table 2 shows various statistics on the transfer time. Taking tcp as a reference, we show the percentage of flows that finish faster and slower. We see that with SRPT and FAIR, more than 88% of the flows finish their transfer earlier than with tcp, and that only 3% of the flows do finish later. LAS reduces the transfer time for nearly 60% of the flows, whereas the performance is worse for 25% of the flows. We also give the average gain and loss, which refer to the average reduction (increase) of the transfer time among flows that finish earlier (later). The overall conclusion is that SRPT and FAIR provide a similar performance gain, and that being size-aware provides a significant advantage to both SRPT and FAIR. 7 Conclusions and future work

The main objective of this paper is to show that the congestion control and scheduling features of TCP can be efficiently decoupled. We have introduced gtcp, a new protocol that permits to implement any scheduling policy among the flows sharing any given route, while preserving the overall impact of these flows on the network. The experiments with SCHED TCP on a real network with have shown that the performance gain can be significant, and that this gain comes at no cost for other flows.

We have focused on size-based scheduling disciplines. This choice allowed us to derive optimality results for gtcp, but the scheduler of gtcp need not be restricted to this particular class of policies. For instance, one could consider giving priority to a certain type of traffic, like interactive traffic, web, email or Skype, over the rest. More generally, the end user could define his own scheduler π, aiming at maximizing his own particular notion of quality-of-service.

SCHED TCP could be incrementally deployed, improving the performance of the flows of any given route, and without harming the performance of any other flow on the network. It could be implemented on the end-hosts, or between two proxies within the network in order to aggregate traffic.

  mss

Figure 2 :

 2 Figure 2: Function C(t) that captures the instantaneous data transmission. The black dots represent time epochs in which a segment is transmitted.

Figure 3 :

 3 Figure 3: Distribution of TCP/IPv4 segment sizes in 2002 and in 2014 on all probing points of CAIDA a Maximum Transmission Unit (MTU) of an Internet Technology, and that at least 60% of data segments are full-sized segments.(iv) Absence of segment losses and reordering. These assumption was needed in order the optimality results of Proposition 2 to hold. In the presence of segments losses and reordering, it is not possible to prove any optimality result, but we nevertheless expect that gtcp can provide an important performance gain over tcp. We also note that if ECN[START_REF] Floyd | TCP and explicit congestion notification[END_REF] were deployed, the optimality results of Proposition 2 would hold even with losses. From the losses point of view, the worst-case scenario is the loss of the last ack for a flow. In such a case, a server would detect the loss with the rto event and all the data sent up to this event would not have been from a priority flow.

Figure 4 :

 4 Figure 4: SCHED TCP implementation with n applications and n TCP connections.

Figure 5 :

 5 Figure 5: Testbed used for the first experiment.

Figure 6 :

 6 Figure 6: Average throughput of 2 flows scheduled with tcp (top) and with SRPT (bottom) that compete with 1 sample flow with tcp policy.

Figure 7 :

 7 Figure 7: Distribution of the number of active connections (regardless of size) with tcp, SRPT, LAS and FAIR policies.

Figure 8 :

 8 Figure 8: Distribution of flow transfer time with different scheduling policies.

Figure 9 :

 9 Figure 9: Transfer time in seconds against flow size in MB. A dot in (x, y) means that a flow of size x has finished its transfer at time y.

Table 1

 1

	: Proportion of schedulable traffic
		Total	Shared/Competing Ratio
	Routes (number)	1788796	102981	5.7%
	Flows (number)	5155554	937033	18.1%
	Flows (volumes in KB) 261769672	152530580	58.2%

Table 2 :

 2 Statistics on transfer time of different scheduling policies. F aster Slower Equal GainLoss

	LAS	61%	25.6% 13.2% -0.57s +314ms
	SRPT 88.8%	3.2%	8%	-1.11s +28ms
	FAIR 89.6%	2.4%	7.9%	-1.13s +33ms

Appendix A: Proof of Proposition 2

The proofs are applications of known results to the modified system with instantaneous transfer time C(t), and we provide a sketch. To be specific let us consider the case of SRPT. Since SRPT is sizeaware, the scheduler has precise information of how many segments each flow needs to transmit in total. Let us assume that gtcp implements a scheduler π, and let R gtcp (t) = (R gtcp n (t); n ∈ {1, 2, . . .}) denote the ordered vector of unsent segments at time t, with the first element R gtcp 1 (t) being the largest number of unsent segments, and let R gtcp (t) denote the total number of unsent segments at time t. Since the total number of sent segments V gtcp (t) = V tcp (t) is independent of the scheduling discipline π deployed by gtcp, it follows directly that the total number of unsent segments R gtcp (t) = R tcp (t) is also independent of π.

We can now invoke [5, Proposition 1], which holds for arbitrary capacity functions C(t), to show that SRPT preserves over time a relation on the cumulative remaining amount of unsent segments. We have that for any π that gtcp may implement, and

We can now give a direct argument to show the optimality of SRPT. Let us assume that N gtcp (t) = n. Then, by [START_REF]The CAIDA UCSD anonymized internet traces[END_REF] we have

The proof of LAS is a direct adaptation of [30, Theorem 2.1]. The DHR assumption intuitively implies that the more service a flow receives, the larger its expected remaining service time is. This explains why the policy LAS is optimal, since by serving flows that have receive less amount of service, the scheduler "guesses" correctly which flow is more likely to finish the transmission earlier.

The proof in [START_REF] Righter | Scheduling multiclass single server queueing systems to stochastically maximize the number of successful departures[END_REF]Theorem 2.1] uses an interchange argument to show that any policy that does not follow LAS in a decision epoch is necessarily sub-optimal.

The result of FAIR is by construction, and is a direct application of [START_REF] Friedman | Fairness and efficiency in processor sharing protocols to minimize sojourn times[END_REF]. Under FAIR all flows will finish their transmission earlier than what they would under tcp, except the flow that transmits the last segment before an inactivity period which will finish at exactly the same moment. To see this we observe that under FAIR, the selected flow will transmit at much higher rate than under tcp. In fact, under FAIR, the selected flow gets to transmit in all the next available transmission epochs until it finishes the transmission. It is then trivial to observe that all flows will finish transmission earlier than what they would under tcp. An exception is the last flow, when R FAIR (t) = 1, this implies that there is only one flow active, and we then necessarily have R tcp (t) = 1. This last flow will finish its transmission exactly at the same time under FAIR and tcp.


Ghislaine Bertrand

David Grossin

Christian Rey

Rev êtements d'hydroxyapatite r éalis és par projection plasma : vers de nouvelles fonctionnalit és Plasma Sprayed Hydroxyapatite Coatings: Towards new functions

Engineered implants for bone and joints replacement very often require coated metallic substrates. The coating is aimed at creating conditions for bone regeneration while still maintaining the bulk mechanical properties of the metallic substrate. Among coating technologies, plasma spray deposition is the most widely used to produce commercial hydroxyapatite coatings. In the present paper, attempts are made to give an overview of latest process developments (suspensions/solutions plasma spray, dc vs rf plasma spray, low energy torch. . . ) as well as materials innovations (doped hydroxyapatite. . . ).

Résumé. Dans les stratégies de remplacement/reconstruction des os et des articulations, il est souvent fait appel à des matériaux revêtus. Le matériau de structure permet d'assurer une bonne tenue mécanique et le revêtement doit faciliter et pérenniser l'ancrage dans le site osseux. Dans ce contexte, la technique de projection plasma est largement utilisée pour réaliser industriellement des revêtements d'hydroxyapatite. Nous proposons ici de faire une revue sur les avancées en termes de procédé (projection plasma dc ou rf, de suspensions/solutions, basse énergie, . . . ) couplé à des compositions d'hydroxyapatite modifiées.

INTRODUCTION

Les pathologies (ostéoporose, arthrose, . . . ) et les traumatismes (fracture du col du fémur, . . . ) du squelette dont les origines peuvent être associées à un vieillissement des populations, mais aussi aux accidents de la route, aux guerres, à certaines activités physiques soutenues, professionnelles ou sportives, sont de plus en plus nombreux (le marché mondial est estimé à 33 milliards de $, en croissance de 7,5 % par an) [START_REF]Rapport «Dispositifs médicaux[END_REF][START_REF]Fiche marché « le marché des implants orthopédiques[END_REF].

10 millions d'individus dans le monde portent une prothèse. Remplacer une articulation (hanche, genou, épaule, coude, cheville, doigt, poignet, . . . ) usée ou défaillante ou reconstruire une perte osseuse (sphère crano-maxillo-faciale, . . . ) nécessite un dispositif médical implantable capable de restaurer les fonctions mécaniques (contraintes mécaniques, usure, fatigue, . . . ) et d'assurer une continuité des fonctions biologiques (croissance des cellules, formation de tissus, . . . ), sur le long terme.

La conception des implants et le choix des matériaux s'appuient largement pour les pièces supportant une charge mécanique sur les matériaux métalliques. Ainsi les aciers inoxydables, les alliages à base de cobalt et ceux à base de titane sont proposés commercialement pour les prothèses articulaires, les implants dentaires ou autres pièces de reconstruction. Au-delà de la durabilité et de la fonctionnalité de l'implant, qui sont des objectifs principalement assurés par les propriétés du matériau massif, la réponse biologique dépend, elle, des caractéristiques de la surface du matériau implanté. En effet, l'étape clé concerne la formation de l'interface entre l'os et le matériau implanté qui peut durer plusieurs mois et consiste en la production, par les ostéoblastes, d'une matrice extracellulaire non minéralisée à la surface de l'implant (ostéogénèse de contact) ou sur la surface osseuse (ostéogénèse à distance). Cette matrice, dite ostéoïde, se calcifie par la suite aboutissant à l'ostéo-intégration de l'implant. Dans ce contexte, les métaux et alliages métalliques présentent, en particulier, de mauvaises propriétés d'ostéoconduction/ostéo-induction ainsi qu'une propension à la colonisation bactérienne limitant ainsi leur ancrage et leur intégration. Pour remédier à ces modestes qualités de surface, des modifications morphologiques (texturation 3D) ou physico-chimiques (implantation ionique, greffage, revêtement) ont été proposées. Les céramiques à base de phosphates de calcium (CaP) et en particulier l'hydroxyapatite (HA) (Ca 10 (PO 4 ) 6 (OH) 2 ), dont la composition est relativement proche de celle de l'os sont, à ce titre, utilisées sous la forme de revêtements depuis plusieurs décades, notamment en orthopédie [START_REF] Paital | [END_REF]. Ce composé «bioactif» favorise la repousse osseuse au contact et la colonisation par l'os permet d'améliorer la fixation primaire entre l'implant métallique et l'os.

La projection plasma est le procédé le plus répandu au niveau industriel pour la réalisation de ce type de revêtement car elle présente certains avantages dont la facilité de mise en oeuvre, de forts rendements de dépôt et une faible température du substrat.

DE LA PROJECTION PLASMA CONVENTIONNELLE À DES M ÉTHODES AVANC ÉES

Le procédé de projection plasma consiste à déposer sur un substrat un matériau fondu ou semi-fondu. Le matériau à déposer qui se présente sous forme de poudre est introduit dans le jet d'un plasma (généré par un arc électrique entretenu entre une anode et une cathode) où il est fondu et accéléré vers le substrat. Là il s'étale et se solidifie en quelques ms. Que ce soit la poudre d'hydroxyapatite ou les conditions de projection par plasma atmosphérique dc, de nombreuses études ont évalué leur impact sur les caractéristiques du revêtement (adhérence, composition, cristallinité, comportement biologique, . . . ). La maîtrise de la poudre (en termes de distribution granulométrique, densité, composition, pureté) est un facteur permettant de contrôler à la fois la chimie du revêtement mais également ses caractéristiques mécaniques. L'effet des conditions opératoires (conditions plasmagènes, distance de projection, . . . ) a été étudié grâce à des outils de diagnostic permettant de connaître température, vitesse et position des poudres en vol et confronté à des résultats de simulation numérique [4,5]. La température joue un rôle critique dans l'apparition de phases secondaires comme CaO ou TTCP tandis que la vitesse influence la porosité et les caractéristiques mécaniques du dépôt (microdureté, module d'élasticité). La défaillance du revêtement par éclatement, écaillage, décollement et dissolution a été observée dans des cas cliniques (après plusieurs années d'implantation). Cette défaillance, localisée à l'interface implant/dépôt, a été attribuée à l'existence d'une couche amorphe de phosphate de calcium (ACP) formée lors du refroidissement rapide des particules projetées [6]. Cette zone est fragile et très soluble, ce qui réduit considérablement l'intégrité mécanique de l'interface et en conséquence celle du revêtement lui-même.

Dans le but de limiter ces effets néfastes dus aux hautes températures des développements ont été conduits en minimisant l'énergie de la torche plasma (nouvelle torche basse énergie) et en projetant des apatites plus stables thermiquement comme la chloroapatite [7]. D'autres compositions à base d'hydroxyapatite (Si-HA, CO 3 -HA, Ag-HA, . . . ) ont également été envisagées dans les dernières années. Notamment Roy et al. ont étudié pour leurs propriétés biologiques, mécaniques et antibactériennes des dépôts d'hydroxyapatite dopée à l'argent, au strontium et au magnésium réalisés par projection plasma inductif à partir de poudres [8]. Bien qu'ayant constaté peu d'effets des dopants sur les caractéristiques microstructurales et mécaniques (taille de grains similaires de l'ordre de 20-25 nm, adhérence identique autour de 17 MPa), une différence des comportements biologiques a été notée. In vitro l'adhésion et la prolifération des ostéoblastes (hFOB) sur les dépôts Sr-HA sont améliorées. La présence de ce dopant semble aussi améliorer la différentiation cellulaire et son activité (ALP). L'ajout de 2, 4 ou 6 % massique d'argent dans l'hydroxyapatite projetée conduit à des revêtements aux propriétés mécaniques inaltérées (adhérence mesurée à 17 MPa avec une rupture cohésive). La libération de l'argent est faible de l'ordre de 1 % ce qui signifie que l'argent reste présent dans le dépôt et peut agir sur le long terme comme agent antibactérien sans altérer l'activité cellulaire des ostéoblastes jusqu'à 4 %. L'addition de strontium à l'apatite dopée en argent permet de contrebalancer l'effet cytotoxique de l'argent vis-àvis des cellules ostéoblastes. Les revêtements préparés avec une buse supersonique (adaptation du système de projection plasma inductif RF standard) sont par ailleurs mieux cristallisés grâce à des temps de séjour dans le plasma plus courts. De plus il est à noter que les conditions plasma retenues (buse supersonique, distance de projection, puissance) ont un effet en particulier sur la taille des cristallites et en conséquence sur l'activité biologique.

Parallèlement aux évolutions de la composition de l'hydroxyapatite visant à conférer au dépôt des caractéristiques biologiques améliorées (intégration et ancrage plus efficient, limitation des infections), le procédé a évolué. L'injection d'une suspension de particules submicrométriques voire nanométriques ou d'un liquide dans le plasma permet de réaliser des poudres ou dépôts finement structurés. Pawlowski et al. ont conduit des travaux sur la réalisation et l'étude de revêtements d'hydroxyapatite par projection plasma de suspensions (synthèse par précipitation puis calcination suivi par un broyage avant la réalisation de la barbotine dans des solvants mixtes eau-éthanol) [9]. Les revêtements ainsi déposés présentent une structure bimodale dont certaines zones sont constituées de HA, TTCP et CaO tandis que les autres sont constituées uniquement de HA à grains fins (particules initiales consolidées par les passages de la torche plasma). Les revêtements ont été immergés dans une solution simulant le plasma sanguin (solution SBF) et une dissolution préférentielle a été observée. L'adhérence mécanique des revêtements après immersion est diminuée de 20 % environ mais la dureté mesurée par nanoindentation ne change pas. Huang et al. ont utilisé la projection plasma de « liquides » pour étudier des revêtements à base d'hydroxyapatite [10]. Ils ont alors obtenu, après avoir validé la qualité de leurs revêtements par des essais biologiques, une meilleure performance en termes de prolifération et différentiation d'un dépôt poreux relativement à un dépôt standard. Ils ont ensuite ajouté des dopants (Ag, Si, Mg, CO 2- 3 , Si/Mg/CO 2- 3 ) sous forme de sels de nitrate dans leurs suspensions avant projection. Ces travaux ont permis d'apporter la preuve qu'il était ainsi possible de doper une hydroxyapatite avec des éléments en site anionique et/ou cationique en maîtrisant les quantités présentes ainsi que d'obtenir une nanostructuration des dépôts (taille des cristallites de 20 à 50 nm). Seul l'effet antibactérien a été testé et lorsque l'argent est associé à une structure poreuse son efficacité a été avérée vis-à-vis de Staphilococcus aureus.

Les derniers développements explorent deux voies : l'une tend à renforcer les caractéristiques mécaniques du dépôt en y incorporant une céramique type zircone et la seconde vise à y associer des agents biologiques (antibiotique lié par un polyCD, protéine morphogénétique BMP, RGD, collagène) [11].


published or not. The documents may come