Tài liệu Pricing communication networks P11 doc

Also, whereas satellite broadcasting typically uses constant bit rate channels, applications that use data network multicasting services may produce bursty data flows and have more flexi

Part D

Special Topics

Costas Courcoubetis and Richard Weber Copyright  2003 John Wiley & Sons, Ltd.

ISBN: 0-470-85130-9

Multicasting

A unicasting service is one that requires the network to provide point-to-point transport

between just one information source and one receiver A multicasting service extends this

idea by requiring the network to provide transport between one or more information sources and a group of receivers Multicasting services can be used for teleconferencing, software distribution and the transmission of audio and video A key characteristic of a multicasting service is that it its cost must be optimized for the particular group of receivers to which it provides service This poses important resource management and control problems, which add new complexity to pricing issues

A special case of multicasting is broadcasting Broadcasting is simple, in that the same

information is continually made available to all potential receivers, and so there is no need

to optimize network resources to the subset of receivers that is presently listening The transmission rates and network resource allocation are fixed, and the transmission cost is independent of the customer group If broadcasting technology is in place, then we can multicast information by broadcasting it, but only granting the subscribers of the multicast the permissions to access or decode it

Multicasting over a data network such as the Internet requires far more complex resource management than does broadcasting This is because there are different mechanisms available at the network level, and the identities of the end receivers can influence routing decisions about which links of the network should carry the multicast traffic Also, whereas satellite broadcasting typically uses constant bit rate channels, applications that use data network multicasting services may produce bursty data flows and have more flexible quality of service requirements In this chapter, we investigate the issues of resource allocation and pricing that arise when multicasting services are to be provided over a data network like the Internet We see that the final resource allocation may depend upon decisions taken by a large number of participants This contrast with unicast, where one of the two connected parties makes all the decisions about the properties

of the connection and is responsible for paying the bill Hence, if one is to achieve globally efficiency by giving appropriate incentives to the various decision-makers, there are many delicate gaming aspects that can make pricing very complex Of course,

we can always view a single unicast connection as the simplest case of a multicast service, in which the sender and the receiver make independent decisions and so must agree on common features of the connection, such as the bit rate and how to split the network charge

Pricing Communication Networks: Economics, Technology and Modelling.

Costas Courcoubetis and Richard Weber Copyright  2003 John Wiley & Sons, Ltd.

ISBN: 0-470-85130-9

In Section 11.1 we set out some requirements for multicasting In Section 11.2 we describe some basic technologies for it Section 11.3 considers mechanisms for providing quality of service and Section 11.4 addresses flow control Starting from a model for allocating bandwidth to elastic multicast traffic, Section 11.5 considers issues of cost sharing and the formation of the multicast tree Section 11.6 is about settlement

11.1 The requirements of multicasting

Multicasting is potentially a very promising network service for IP technology networks Great efficiency can be achieved by arranging that only one copy of the data transverses any common paths on its way towards multiple destinations For example, in satellite broadcasting there is a single common path; all receivers share the same set of broadcast channels, all of which are transmitted over the same link

Multicasting services provide positive network externalities Since a customer shares common cost with other customers he can access services that he would otherwise find too expensive However, there is a negative externality, since a customer may not be able to choose the precise type and quality of the service that he desires His choices are restricted because other customers in his multicast group value service differently or have different technological capabilities These issues make the pricing of multicasting services interesting, but complex As for unicast services, pricing plays an important role in controlling the way network resources are shared A pricing policy must fairly reflect the externality effects and provide the right incentives for customers to join or leave a multicast session when it

is economically justified from the viewpoint of the multicast group as a whole

Before looking at the economic aspects of a multicast service model, we consider the technology aspects Clearly, multicast services can provide savings in network resources Savings occur because network routers and switches can, at no cost, copy incoming packet flows and direct resulting identical flows to more than one output link The network gains

by taking information that is destined for multiple receivers and forwarding it over paths for which receivers have common parts An inefficient network could always use traditional unicast technology to support a multicast service However, this would lead to unsustainable prices since a competitor who uses multicasting would have lower transmission costs and

so could offer lower prices

The resource savings of multicast come at the cost increased complexity Some difficult tasks are the scheduling of the multicast packets at the routers, the routing of the packets inside the network, addressing, congestion control, and quality of service issues, such

as the reliability and variability of transmission These are the subject of undergoing research Furthermore, many decisions depend upon the assumptions that are made about the semantics of the multicast service, and these are often not precisely defined The optimal solution of some fundamental multicast problems, such as constructing the least cost multicast tree, are very difficult and cannot be solved under practical assumptions

It is important to distinguish between multicasting’s network implementation and multi-casting viewed as a service For instance, multimulti-casting’s network implementation through IP

is based on standard IP unicast concepts, which allow IP packets originating from a set of sources to reach a set of destinations The semantics of such a lower-level network service are similar to IP: packets are transported unreliably, with no guarantee on synchronization

or delay By contrast, a multicasting service at the application layer may have requirements for reliability, an upper bound on packet delay, and a minimum rate guarantee It may also require there to be mechanisms for group management (controlling who joins or leaves the

MULTICASTING MECHANISMS AT THE NETWORK LAYER 265 multicast group), negotiating various economic and service specific terms, and charging customers The network provider may use a lower-level service, such as IP multicast, and then add some additional protocols to meet these requirements, or he can use other mecha-nisms For instance, he may substitute unicast services if these can better provide the desired service quality, although the economies of scale produced by the specialized multicasting technology should make this rarely advantageous In practice, multicasting services as seen

by the end customer, are mostly defined in a bottom-up fashion They are not shaped by the demand for some killer application, but by the capability of the multiplexing-specific technology that have been implemented at the various network devices

The problem with such a ‘technology-centred’ approach, compared to one that is

‘application-centred’, is that present multicasting technology has limited capability for supporting real-world, revenue-generating services For example, the simple IP multicast service model, based on existing IP multicast technology, is suitable for simple low quality teleconferencing applications However, it seems overcomplicated for software distribution

or TV-like applications, where only one source exists and group management and payment capabilities are of great importance Indeed, the presently deployed ‘open’ IP multicast service model was not defined with a commercial service in mind, and poses severe technical restrictions to most reasonable charging mechanisms The absence of group management from the model and the increased routing complexity, are perhaps the most important reasons why there has been slow deployment of multicast services in the Internet thus far The fact that there are as yet no well-defined multicast services at the application layer leaves research in these areas truly open

As far as pricing is concerned, some very important questions must be answered Cost-based pricing for multicast services is strongly tied up with game-theoretic notions of bargaining and arbitration Since transmission cost is partly common, how should it be shared amongst the members of a multicast group? Should a customer who obtains greater value from a service pay a greater fraction of the common cost? Clearly so, since customers who obtain less value will leave if they obtain negative net benefit when they are asked

to pay equal share of the cost What pricing mechanisms will make users reveal their true utilities? A multicast service may be offered in an uncertain and dynamically changing environment The number and identity of the receivers may not be known in advance, but fluctuate during the multicast session How can one reduce the risk of customers paying exceedingly high prices when there is small participation, or reduce the risk to the provider

if prices are fixed at the start? If the service can be offered at various quality levels, but only one will be actually selected, perhaps because of a constraint imposed by the receiver with the slowest access link, how should one charge such a receiver? How could one give

an incentive for that receiver to leave if that would increase the value of the service to all other receivers? These questions illustrate the diversity of the issues that must be addressed, and the complexity of designing a sound pricing policy

In the following sections we extend the models that we have used for unicast flows

to discuss the state-of-the-art in different research areas that are relevant to pricing multicast services

11.2 Multicasting mechanisms at the network layer

The range of applications that multicasting can support depends strongly on the capabilities

of the network technology Important high-level features include mechanisms for knowing the exact number of receivers, controlling access and transmission, providing security, and

obtaining the quality of service required for the transport of the packet flows In practice, the network provides some basic mechanisms with simple features, and other mechanisms must be built on top to fit each particular application

The basic multicasting technology proposed for the Internet is IP multicast In keeping

with the Internet philosophies of openness and simplicity, its service model defines the notion of a ‘multicast group’ as a group of computers connected to the Internet, which

at the network layer is identified by one specific IP address Any host on the Internet (member or not of the multicast group) has an equal right to send packets to, or receive packets from, members of the group A packet received by one member of the group (i.e with an IP address of the multicast group) will be forwarded by to all other members of the group in a best-effort fashion, similar to a standard IP packet The packet will follow a tree

of routers (i.e a ‘multicast tree’ that connects the sending computer to all other members

of the group), and will be duplicated at each branch of the tree

There is no control over who joins or leaves the group, who transmits to the group, and there is no knowledge at the network layer of the identity and number of the subscribed members A receiver makes its subscription request to its edge-routers (i.e the router in its LAN that is a node in the multicast tree of routers) using the Internet Group Membership Protocol (IGMP) The wide area multicast tree is constructed by a network layer multicast routing algorithm/protocol such as PIM, DVMRP, CBT or MOSFP

Two approaches have been adopted for constructing this multicast tree, each with many variations The basic difference between the two approaches is in whether the routing tree that is used to distribute the traffic is the same or different for each sender in the group If

it is to be the same for all senders, the so-called ‘group-shared approach’, then one might like it to be the tree of routers that connects all the members of the multicast group at least

cost However, finding this tree is related to the Steiner tree problem, which is known to

be NP-complete Instead of trying to find an optimal tree, one could use the ‘centre-based approach’, which constructs the shared tree by first identifying a centre router (the ‘core’ for the multicast group Subsequently, each edge-router in a LAN with a host that is a member

of the multicast group sends a ‘join’ message to the core router The paths followed by the join messages define the multicast tree If each sender is to have its own specific routing tree

to all destinations, the so-called ‘source-based approach’, then each such tree should ideally approximate the optimal Steiner tree We already mentioned that solving such problems is hard To provide a practical solution, some protocols in the Internet use existing underlying unicast mechanisms to set up trees from each source to the destinations, and then merge these where they overlap An example of both approaches is shown in Figure 11.1

In practice, network operators have been slow to deploy IP multicast because they are reluctant to risk the stability and efficiency of their network to such an uncontrolled service without the opportunity to extract corresponding revenues Note that there is no flow control

on information transmitted over the multicast tree: a single source could end-up flooding a large part of the network

Some important features that are missing from the present multicast service model, but which are necessary for a simple and efficient pricing structure, are receiver counting, authentication and access control There are addressing issues, which arise because multicast addresses are not controlled by a central Internet authority and so a newly created multicast group may choose an address already used by another group There are inter-domain routing difficulties, due to different ISPs using different routing algorithms for constructing their parts of the multicast tree These issues are presently motivating a search for new multicast routing approaches based on different service models

QUALITY OF SERVICE ISSUES 267

S2

S1

router with attached multicast group members router with no attached multicast group members

C

Figure 11.1 Group-shared and source-based multicast trees In the group-shared tree there is a

single common tree for the entire multicast group, and it could be constructed by defining router C

(shown by dotted and solid line, respectively), and every other potential sender of the group

11.3 Quality of service issues

Quality of service is a generic notion, but it is most commonly associated with the ability of

a network to provide deterministic or statistical delay and bandwidth guarantees, especially for multimedia real-time applications Present proposals for improving existing IP network technology are mostly unicast in nature, and do not address the requirements of such multicast applications

Although multicasting could benefit if quality of service mechanisms were available, their slow deployment in the present best-effort Internet discourages the use of multicasting for high-value commercial services such as TV and video broadcasting As a result, these services continue to be delivered over specialized networks of satellite or fibre, which offer guaranteed quality; they are then combined with broadband access to the customers (by, for example, using cable) However, new encoding mechanisms, which require lower bit rates, improved network technology such as Differentiated Services (see Section 3.3.7), and intelligent end-devices, are beginning to make the Internet attractive for multimedia transmission when applications have less strict quality requirements, and can adapt to varying network conditions

We now turn consider a number of questions What are the intrinsic differences between multicast and unicast applications? Do applications that rely on multicasting services have similar quality of service requirements as typical unicast applications? By what mechanisms can the network to provide the performance that multicast applications require?

11.3.1 Multicast Application Requirements

It is useful to distinguish between multicasting applications for which either reliability or timing is the more important Take, for example, the distribution of a database Here, reliability is paramount No data should be lost or altered Timing may be relatively unimportant, as there may be no hard constraint on when all receivers should have received their copy of the database In contrast, if one is distributing a real-time video of a sports event, then timing is key; loss of a small fraction of the information may not noticeably degrade the quality of the video, but the information must travel regularly, incurring small delays and jitter Thus the network must ensure a regular and even flow on all links of the multicast tree This is not required if the content is not real-time, for then any positive rate allocation along the links of the tree (not necessarily uniform) can suffice

One can imagine even more ‘exotic’ requirements For instance, it could be essential for a real-time, cooperative work application that data be delivered to all members of the multicast group simultaneously In this case, the delay jitter of the information across receivers in the group may be important

In practice, things are complicated further by the fact that members of a multicast group may differ For example, suppose a video transmission can be encoded by the sender as

a 1 Mbps (low quality) or as a 2 Mbps (high quality) stream There are several types of receivers: some are linked to the network with access bandwidths of less than 2 Mbps, and so while all can decode the low quality encoding of video only some can decode the high quality One solution is to use a single multicast tree with enough resources to satisfy the minimum common requirements, i.e to distribute low quality video Another solution

is to use two independent multicast trees, for the low and high quality, each reaching the relevant members of the group This solution maximizes the value of the service to the customers, but costs more Cost of the second solution can be reduced using a ‘layered’ encoding technology, in which the added quality in the high quality video is transmitted as

an extra 1 Mbps stream on top of the low quality stream Accessing both streams allows

a decoder to offer the high quality playout, whereas accessing only the low quality stream remains a valid possibility Now a single tree can be used All receivers receive the low quality stream The high quality stream passes only through nodes that eventually reach receivers who want high-quality video

If the above idea of layered trees is used, then maintaining the appropriate trees is likely

to be very complicated, since a fluctuating congestion level will make the higher bit rate more or less expensive as receivers join or leave If dynamic pricing is used then the cost

of supporting the various quality layers over the links of the tree may change during the multicasting session The receivers should be notified of the ongoing cost of the service and be allowed to choose the number of layers (and hence the quality) that they wish to receive This may be a complex task for a receiver Even more difficult is the problem of sharing the cost amongst the receivers This could be addressed in the more general context

in which prices are designed to offer incentives for resource usage that achieve maximum economic efficiency for the group as a whole (see Section 11.5)

11.3.2 Network Mechanisms

Other mechanisms can be used to complement the simple service provided by IP multicast Most of these are extensions of mechanisms for unicast connections We have made a distinction between requirements for reliability (when distributing content that is not real-time) and for timing (when transmitting real-time content) The latter also usually has some requirement for a minimum average information rate over all links of the multicast tree

In unicast, reliability is achieved at the transport layer using the TCP protocol, or at the application layer with various mechanisms (if UDP is used instead of TCP) In multicast, there are two problems that make reliable transmission at the transport layer very difficult The first problem is that of ‘feedback implosion’, which occurs when one packet loss causes many members of the same multicast group to generate loss signals A solution is to aggregate/suppress loss signals on their way up-tree towards the sender The second problem

is that of ‘efficient retransmission’, which has to do with suppressing the re-transmission of lost packets to receivers that have already received them This problem can be addressed either by local lost packet recovery (through designated receivers, routers, or repair servers)

or by making the routers remember the links from which loss signals arrived, so that retransmission can be efficient

FLOW CONTROL MECHANISMS 269 There are some other interesting technologies that can be used for reliability For instance, the Digital Fountain technology eliminates the need for specific retransmissions The file is

first encoded using a special encoding scheme, and then divided into n packets which are

continuously transmitted in a circular fashion A receiver can reconstruct the complete file

if he receives correctly any m out of the n packets, for some m < n.

Multimedia applications have different requirements When information is transmitted in layers, each layer having its own bit rate, then the network must reserve the appropriate bandwidth over the links of the multicast tree to transmit the information If the network is best-effort, as in the present Internet, there is no mechanism for guaranteeing such average rates The problem can be solved if the network implements some bandwidth reservation protocol, such as RSVP (see Section 3.3.7), or has a dynamic pricing mechanism, so that any amount of bandwidth can be obtained by paying the appropriate price (see Chapter 10) However, in a best-effort network, even if such a desired average rate can be achieved over the links of the multicast tree, one has to compensate for the fluctuations that cause packets to queue at the routers and so reach the receivers as an irregular stream of packets

A simple way to eliminate this delay jitter is to use buffering at the receiver end The sender time-stamps each packet with the time it is transmitted The application at the receiver end looks at the time stamps and estimates the average rate and its variance Arriving packets are stored in a buffer, from which the application picks packets at regular

intervals and feeds them to the display device This is known as streaming Streaming

allows playout to start before all the data is transferred from the source to the receiver Obviously, the average rate at which packets enter the buffer must equal the rate at which they are picked out By knowing the statistics of the rate at which the buffer fills, the receiver can compute how large the buffer must be initially, so that once playout starts the probability that the application should ever request a packet and find the buffer empty is very small

An alternative method to streaming would be for a receiver to wait until it has received from the sender the complete data for the video and then play it from a file in its memory The drawback is the delay in starting to view: it may take much longer to transfer the complete file than to transfer the initial small part of the file that is required by streaming There already exist commercial streaming products, such as QuickTime and RealOne Player The information needed for streaming is standardized through the Real Time Protocol (RTP), and feedback statistics about the connection’s losses, jitter, and so on, are sent back

to the sender using the Real Time Control Protocol (RTCP) Of course, streaming could become obsolete if there were abundant bandwidth, both inside the network and in the access part

11.4 Flow control mechanisms

Flow control is used to control the rates at which information flows in the network In practice, it is implemented with two components The first component is part of the network technology: it generates flow control signals and communicates them to the entities that are responsible for generating or receiving the traffic These entities are usually the applications that contract the network services The second component resides in these applications

It receives the flow control signals and reacts by appropriately adjusting the rate of the information flow Note that flow control signals could be prices, giving the price per unit flow at the given point in time In this case, a rational application will adjust its use of the network so as to maximize its net benefit, that is, the value of the service minus the charge

as a function of the information rate

Flow control signals could be sent to senders or receivers It is a matter of implementation details as to which parties receive them It can be helpful to think of all parties as constituting

a single application For instance, in a multicast session, the application could be taken as all senders and receivers These would internally decide how to react In unicast the sender simply reacts by adjusting his sending rate to the unique receiver In multicast, many actions are possible One could decide temporarily to drop some receivers from the group, hence resulting in a smaller multicast tree Or, in the case of layered multicast, one could constrain some receivers to subscribe to a smaller number of information layers, thereby reducing the total data rate in certain parts of the multicast tree This can be accomplished by assigning

a different multicast group to each layer, and dynamically forcing receivers to subscribe and unsubscribe to the corresponding groups

Let us investigate the multicasting flow control in more detail For simplicity, assume that there is a single sender in the multicast group, and that each link of the multicast tree generates flow control signals that reflect congestion of the link We can distinguish applications in respect of their ability to adapt to flow control signals Suppose that data is transmitted into a single layer, in which receiver membership is fixed, and so the only available control is the sending rate In this case, the sender must explicitly compute one common rate for all receivers, perhaps by adjusting the sending rate to the congestion signals generated by the most congested path in the multicast tree A way

to implement this is as follows Congestion signals are implicitly modelled by packet losses Receivers produce negative acknowledgments (NACKs) upon packet loss, which are sent to upstream routers A router filters such information and forwards up-tree NACKs

at the maximum rate these are received from any of its downstream links Clearly, the sender sees a rate of NACKs corresponding to the path to the worst receiver, and adjusts his rate accordingly For instance, he might use the TCP-like rate adaptation scheme PGMcc The sender computes the worst receiver according to loss rate and round trip time information that is added in the NACK packets, nominates that receiver as the

‘representative receiver’, and runs a TCP-like window based congestion control algorithm with it This is the only one that sends positive ACKs upon a packet reception Note that a receiver with a slow access link will restrict the rate of transmission to the whole group

Now suppose a multi-rate layered scheme is used, in which each receiver can choose

to receive a subset of the layers The sender need make no adaptation, and all the control can be exercised at the receiver end Receivers are faced with flow control information and

it is up to them to react by increasing or decreasing the number of layers they receive Note that when a receiver subscribes to a layer, the information in this layer must reach the receiver This increases the total flow of the multicast tree over a path connecting some internal node of the tree to the receiver This node is the root of the largest subtree to which the given receiver is the only subscriber to the particular layer The advantages are that there is no need for feedback to the sender nor a compromise in quality due to a ‘slow’ group member However, it is not obvious how congestion information generated in some internal link of the tree should be propagated down through the tree to the receivers For instance, if congestion signals reflect congestion cost, then this cost should be shared by the receivers But how should this cost be shared? In more general terms, what incentives should be given to the receivers through the flow control signals to subscribe or unsubscribe

to the various layers, and what is the underlying optimization problem? We return to these questions in Section 11.5

THE ECONOMIC PERSPECTIVE 271

11.5 The economic perspective

11.5.1 A Model for Allocating Multicast Bandwidth

Let us extend the proportional fairness model of Section 10.2 to multicasting Suppose a multicast group consists of a single source and a fixed set of receivers and multicast tree There is a single rate that is to be sent to all receivers and which can be adjusted by the sender There is contention for bandwidth at each link of the multicast tree, since there are other connections that share the resources of the network with the multicast group As before, we seek to use prices to regulate flows and optimize the overall economic efficiency

of the network We discuss the similarities with the case of unicast flows and indicate the new issues that arise

The multicasting problem differs from that of unicasting because many entities are involved, each of whom obtains a different value from the service and contributes to a common cost Suppose the members of the multicast group agree to pick a representative, who is given full information about the utility functions of all the group members, and is delegated to make choices that maximize the net benefit of the group as a whole Faced with the prices that the network communicates through the flow control signals, the representative will make a rational decision and choose the optimal rate for the sender to transmit Given more authority, he could decide that some receivers ought temporarily to leave the group if they add more to the common cost than the extra utility they bring Furthermore, he could decide, according to some pre-agreed fairness criteria, what contribution each receiver should make towards the total cost of the service

In practice, some of the members of the group, knowing how the cost will be shared, may have an incentives not to cooperate They may feel they are in a stronger position to obtain a larger share of the overall net benefit Interestingly, it is the hidden information about utilities of the members of the group that makes the problem hard In our unicast model we did not face such issues, since we assumed there was a single entity, the sender, who has full information and full control We can make these clear with a model

Consider a model of a network in which there are sets of links and routes Each route is associated with either a unicast user or a multicast group user and requires some subset of the links The route associated with a multicast group is a tree of links rather than a path

A unicast user r has a utility for a flow of rate x r along route r of u r x r/ A multicast

group r consists of a set of users, r1; : : : ; r n r, these being the sender and the receivers

of the group Each member r` has its utility u r`.x r / for a multicast flow rate x r, and we

denote by u r DP

l u r`.x r / the total utility of the group r The unicast and multicast users

have elastic utilities; that is, their utility is assumed to be increasing, strictly concave and continuously differentiable Our aim is to maximize the social welfare subject to constraints

on the capacities of the links Similarly as in Chapter 10, we have the SYSTEM problem

SYSTEM: maximize

x ½0

X

r

u r x r /; subject to Ax  C

where A jr D1 or 0 as j 2 r or j 62 r We will use the terminology of user r to refer to a unicast user or to a multicast group associated with route r

Suppose user r may choose an amount to pay per unit time,wr Then he receives a flow

x r Dwr=½r, where½r is a price per unit flow on route r The network chooses the price