Rate Control for P2P over IP Networks
6.1 P2P over IP Network Model
We extend the P2P network model of Section5.1by the underlying IP network. Hence, the resource allocation is modelled as a cross-layer optimisation problem and functionalities of the transport and application layer are studied concurrently. In general, we say the network consists of three different entities. Besides the set of service providers or servers and the set of service customers or clients, which are also used in Chapter5, we add the set of links or service carriers known from Chapter4to the new model. We associate a client with a user, which requests a file for download. To differentiate between the different entities we introduce the set of serversS, the set of clientsC, and the set of linksL. The capacity of the servers and the links is finite and is denoted by C.
In a P2P application that supports a multi-source download a client uses several flows to different servers to download a file. We denote the set of servers that can be used by a client c as S(c). The other way around C(s) is the set of clients which can be served by server s. Furthermore, we define a flow as a rate allocation from a server s∈ S to a client c∈ C over a route, which is a non-empty subset of all links, denoted asL(s,c). To identify a flow that uses the link l we introduceδscl , whereδscl =1 if l∈ L(s,c)andδscl =0 otherwise.
Suppose the utility of a client c is defined by a utility function Uc, which depends on the total download rate yc, where yc is the sum of the rates xsc from all servers which are known to c and have parts of the file in which c is interested in. We model the resource
6.1 P2P over IP Network Model
allocation for an IP network with a P2P overlay as a global optimisation problem P2P+IP SYSTEM :
Hereby, maximising the aggregated utility of the service rate ycover all service customers is the objective of the whole system. The problem is constrained by the capacity at the servers and the links. Although servers and links face the same constraint, we differentiate between both in the model, because of their different functionalities: A server can freely allocate its bandwidth over its clients, whereas a link only forwards or discards packets.
As in Section 5.1 with a concave, strictly increasing utility function this optimisation problem has a unique optimum with respect to yc. The rates xscare not necessarily unique at the optimum, because different rate allocations may sum up to the same total download rate yc. Thus, many possible rate allocations may exist with respect to xsc.
The Lagrangian of (6.1)-(6.5) is LP2PIP (x,y,λ,µ,ν,m,n) =
∑
interpreting the Lagrange multipliers as prices we sayλc is the price per unit bandwidth offered by the client c andνsandµlare prices per unit bandwidth charged by the server s and the link l, respectively.By looking at the Lagrangian in (6.6) we see that the global optimisation problem in (6.1)-(6.5) is separable into sub-problems for the clients, the servers and the links. Furthermore, maximising the total of a sum is equivalent to maximising each summand. Hence, we can
decompose the Lagrangian into the sub-problems CLIENT c :
maximise Uc(yc)−λcyc (6.7)
over yc≥0 (6.8)
SERVER s :
maximise
∑
c∈C(s)
λc−
∑
l∈L(s,c)
µl
!
xsc (6.9)
subject to
∑
c∈C(s)
xsc≤Cs (6.10)
over xsc≥0 (6.11)
LINK l :
maximise µl(Cl−ml) (6.12)
over µl≥0. (6.13)
Here, for each sub-problem only locally available information is needed. Only a server needs to be informed about the price offers λc of all connected clients minus the prices charged by the links along the used route.
The economical interpretation of the sub-problems is as follows. A client is selfish and tries to maximise its own utility, which depends on the rate yc. However, the client has to pay a price for using bandwidth. Sinceλc is a price per unit bandwidth, the product λcycreflects the total price that client c pays. On the other hand a server gets paid for the allocation of bandwidth. It is interested in maximising its total revenue. The total revenue is the sum of the revenue for each client, which is computed with price multiplied by quantity. The price the server earns for a unit bandwidth is the price paid by the client minus the cost charged by the links which are needed for forwarding the traffic to the client. Thus, also the server behaves selfishly since it is interested in its own revenue only.
Therefore, it will allocate bandwidth preferentially to flows, where clients pay a high price and costs for using the routes to the clients are low. Also the links maximise their revenue.
As outlined in Section3.3the slack variable mlis interpreted as the spare capacity. Hence, subtracting ml from the capacity Cl reflects the total rate of forwarded traffic of this link.
By multiplying it with the price per unit bandwidth charged by the link we obtain the revenue of that link.
As already well studied in the previous chapters we set the utility for all clients to the logarithmic function in (3.6). This utility function ensures a weighted proportional fair
6.2 Distributed Algorithm
resource allocation. Furthermore, in the context of P2P networks the willingness-to-pay can be interpreted as the contribution of a peer to the network. Thus, we could set it to the upload bandwidth, which peer c allocates to the P2P application.
Using (3.6) the optimum (y∗,λ∗) of (6.1)-(6.5) can be computed by differentiating the Lagrange function in (6.6) with respect to yc and xsc. Hence,
y∗c =
∑
s∈S(c)
xsc= wc
λc∗ if S(c)6={} (6.14)
λc∗=νs∗+
∑
l∈L(s,c)
µl∗ if xsc>0 (6.15)
≤νs∗+
∑
l∈L(s,c)
µl∗ if xsc=0. (6.16)
Furthermore, we deduce from∂L/∂ns=−νsand∂L/∂ml=−µlthat the price at a server or at a link is only greater zero, if the corresponding slack variable is zero. Since the slack variable is interpreted as the spare capacity, in equilibrium a price is charged only when the resources are fully used and competition for a resource is present.
In case the bottlenecks of the network are the uplink connections of the servers and all link prices are zero, the model reduces to the one discussed in Chapter5and results of the parallel bottleneck model in Section3.4apply.
6.2 Distributed Algorithm
An implementation in a decentralised architecture can only use locally available informa-tion. Thus, the problems CLIENT, SERVER and LINK from Section6.1provide a good starting point for the development of a distributed algorithm. CLIENT is an optimisation problem with respect to yc, but in a real implementation a client has no direct influence on the total download rate. It can only vary its price offer λc. Similar, a link has only influence over its load by varying the charged price. This price depends on the level of congestion. We assume that a server receives the difference of the price offered by a client minus the price charged by the links along the used route and adapts its sending rate to the client. Based on Algorithm1we propose the Algorithm3for combined rate control in P2P over IP networks. Like in Chapter 5 the parameters ε and η are small positive constants for probing the network conditions. In contrast to Algorithm1 a server adapts its service rate not only on the priceλc offered by client c, but on the difference of it to the prices charged by the links of the route. Hence, the remaining price offer from client c