The Direction of Value Flow in Multi-service Connectionless Networks

Abstract

This paper argues that, for scalability, all network providers in a connectionless multi-service network should offer each class of their service to each neighbour for each direction at a single price. This is called 'split-edge pricing'. To preserve scalability, if sets of customers wish to reapportion their networking charges between themselves, this should be tackled end-to-end. Edge reapportionment should not be muddled with networking charges, as is the case in the telephony market. Avoiding the telephony approach is shown to offer full reapportionment flexibility, but avoids the otherwise inevitable network complexity. 'Split-edge pricing' is recursive, applying as much to relationships between providers as to edge-customers. Various scenarios are discussed, showing the advantage of the approach. These include phone to Internet gateways and even inter-domain multicast conferences with heterogeneous QoS. The business model analysis suggests a new, purely financial role of end-to-end intermediary in the Internet industry.

Keywords

1. Introduction

The connection-oriented mind-set also leads to confusion over blame and liability for each unit of communication. This paper explicitly clarifies these issues, which are crucial to charging strategies. Our minimalist model for a connectionless network business has boundaries that match the service access points above and below the network layer of the OSI stack [Zimm80]. This business can be modelled as buying in lower and higher layer services (e.g. links, virtual connections or naming services). It still applies to ISPs that use their own links and services - the cost just becomes internalised.

This paper proposes a simple charging model that can be applied between any pair of multi-service connectionless networks for each class of service and for send and receive separately. It works whether the pair are both providers or even if one is an edge customer. The model's simplicity ensures charging will always be straightforward at every border in the Internet. However many networks are connected together, any one network is only dependent on prices from its direct neighbours. Therefore, the model is intrinsically scalable. We call the model 'split edge pricing'. From the end customers' points of view, this means that any flow through the Internet is sold on entry and on exit. As a consequence, the model appears to restrict all end customers to each have to pay the price of their local network provider. This appears to restrict any customers who would rather reapportion the costs differently between themselves (termed clearing).

Invariably, network providers offer their services at a set price regardless of the value each customer derives from each transmission. This is a natural consequence of a competitive market, often called a "buyer's market". If usage-based charging is in operation, no one bothers with any communication of less value than this market price. However, transmissions naturally have at least two ends. (In fact, in this paper we consider two-ended flows as just a specific case of multipoint flows.) Often a transmission just never happens because one of the ends derives less value than their local price. Often in such cases, the total value derived from the transmission by all ends would have been greater than the total charges levied by all providers on all end customers. Therefore, it is in any network provider's interest to matchmake customers who derive surplus value with those who would otherwise be in deficit. That is, clearing plays an important role in encouraging network demand.

Matchmaking in the traditional telephony market is well understood. Various ways are available for end customers to share the cost of a call besides the normal 'originator pays'. Examples are 'calls free to the originator', 'local charge only' etc. Telephony interconnect arrangements ensure that wherever payment enters the system, it ends up being cleared between the providers who bore the cost of each call. However, the interconnect pricing scheme that drives clearing blurs the distinction between clearing of edge payments and the market price of interconnect. This paper argues that these over-complicated clearing arrangements are the result of evolution from a fully connected matrix of single country providers and are flawed for the Internet. Instead we propose 'split-edge pricing' as a more flexible replacement. The apparent problem of no flexibility to clear between the ends is solved simply. Clearing can be achieved end-to-end, directly between customers or their edge providers, bypassing the core network businesses. If instead, clearing follows the same path as the data flow, we show that core network complexity becomes inevitable. Incidentally, end-to-end clearing was never possible on the PSTN because there was no convenient way to form independently routed end-to-end data connections simultaneously to call progress. Clearly, this is possible on the Internet.

Clearing requirements will differ on a per session basis, therefore the model where clearing takes place end-to-end involves per-session accounting without involving the network providers along the data path (other than those at the edge). Thus, it seems natural for clearing to re-use existing e-commerce concepts and mechanisms. This results in a scenario where the traditional telephone bill becomes an anachronism for the Internet. Instead, edge-provider charges can be settled by any other third party across the ends of a communication, leaving the 'bill' as just the balance of those charges that are directly retailed between the edge-provider and its edge-customer. E-commerce-based clearing allows part of local customer A's usage to be 'wholesaled' to remote customer B or to third party C. While part of customer B's usage can be wholesaled to customer A and so on.

The cost of the act of clearing is significant; therefore it is important that the default apportionment in the core model matches the most common case. We establish that the common case is where both senders and receivers pay, at all ends of each transmission. This incidentally causes the perceived need for the network to report how many receivers are subscribed to a multicast to evaporate. We then consider the unpleasant fact that, on the Internet, a receiver can never protect itself from being sent to. We suggest a rather novel business model that is still optimised for the common case, but simultaneously has no receiver liability. For completeness, we examine the specific problems with the traditional clearing model used in telephony. The paper draws to a close by working through some example scenarios to suggest how the models would work in practice. Finally, limitations and further work are listed before conclusions are drawn.

2. Related Work

Clark analyses the apportionment of charges between senders and receivers [Clark96], and proposes an engineering solution, which he admits would introduce considerable complexity to the Internet if implemented. Shenker et al describes edge pricing [Shenker96], a business model that appears regularly in communication networks and which forms much of the background to this work.

3. The value of place

However, because the data communications market is fairly competitive, charges for communicating information tend instead to follow the 'cost plus margin' rule. This is particularly so because it is very difficult for providers to predict what value their customers put on moving any one piece of information.

Any payment to an edge-network provider has the two aspects -  'who pays' and 'who is paid'. 'Who is paid' can only be each local provider collecting its local price. With competitive 'cost plus' pricing there is no scope for any provider to break out of that. But, because communications naturally involves at least two parties, in order to cover the total costs of all the providers involved, 'who pays' can be on a different apportionment. The edge customers do know the value to them of having the information at a certain place. Thus, although apportionment is difficult for network providers, it is very relevant to edge-customers. Clearly, the network providers can stimulate more use of their networks by making arrangements for customers to efficiently apportion costs between themselves.

4. End-to-end pricing

Fig 4.1 - 'End-to-end pricing' role

Telephony firms have traditionally offered end-to-end pricing because they are selling an application. The role of network provider has always been muddled with selling the end-to-end application. This is already putting considerable strains on the International Accounting Rate System (IARS) [ITU_RIARS] with potentially s(n-1)² prices having to be negotiated (where n is the number of edge providers and s is the number of global schemes for sharing the proportions of the price between the ends, e.g. local rate only, free to sender). In practice, end providers are grouped together to reduce the number of prices presented to customers. The PSTN uses addressing conventions (e.g. +800 for free to sender), but this limits commercial flexibility to the few schemes that are widely recognised. Clark proposed an Internet-based solution to allow flexibility [Clark96]. However, catering for various combinations of sender and receiver payments through the core of the network needs packet format changes and router involvement. Further, wholesale prices between providers would have to be negotiated for every possible scheme for sharing charges between the two ends as well as for every possible grouping of end points beyond that boundary. Worse still, inter-provider accounting would then require traffic flows to be isolated then further sub-classified by how much each end was paying on a per-packet basis.

The 'n² problem' would still exist for our end-to-end pricing solution but this is fairly easy to contain by grouping. An example scenario is given at the end of the paper. Importantly though, end-to-end pricing gets rid of all the inter-provider problems described above. There is no longer a need to identify end-to-end flows at inter-provider boundaries. Thus inter-provider charging could be based on bulk measures like average queue lengths, number of routing advertisements etc. Also, most importantly, end-to-end pricing can be introduced without changing the Internet at all, and it allows future flexibility. To summarise so far, we should ensure any discrepancy in the willingness to pay across end customers is normalised end-to-end first, so that edge ISPs always receive payment at their local price.

5. Common case value apportionment

Fig 5.1 shows a generic scenario with multiple networks, N, all connected to the network of interest, N_b. Each connected network has a status relative to N_b based on whether it provides more or less connectivity to other hosts at that class of service. Although the diagram gives the impression that N_b is a backbone network, any one of the neighbouring networks could be a simple link to an edge customer's single host. The model is designed to be general enough for N_b to be an edge customer, an edge network, a backbone network or some hybrid. Those networks with the same suffix are of similar status relative to N_b. For instance, those labelled N_c may be edge customers, N_d may be equally large backbones and N_e a peer network.

In fact, this is a simplification. To be more specific we propose that a provider should offer each class of service in each direction at a separate price. Thus, Fig 5.1 shows the situation for one of possibly many classes of service. Class of service is defined as a unique combination of the service mode (unicast, multicast) and quality (latency, instantaneous bandwidth, reliability, jitter). Quality specifications within one class may leave one parameter to be specified by the customer while others remain fixed, thus generalising both RSVP and diffserv [Zhang93, RFC2475]. Appendix A justifies treating each class of service independently. Appendix B gives the full model for each class of service, but allows heterogeneous QoS per leg of the multicast. However, all this detail would obscure the summary of the analysis we attempt to give here, which we now continue.

Fig 5.1 - Split-edge pricing

A packet of a particular class of service is shown being multicast from N_a into N_b and onward into the other networks. Because multicast is a general case of unicast this allows us to model both topologies. We will also be able to treat the topology as aggregation⁽ⁱ⁾ by reversing the direction of transmission. The term packet is used, but the arrows could represent flows of similar class packets for a certain time. Fig 5.1 highlights the pricing between networks N_a and N_b. W_bas and W_bar denote the per direction weightings applied to the 'nominal charge' that N_b applies to N_a (for more detail on exactly what the nominal charge means, see Appendix B). W_abs and W_abr likewise weight the charge N_a applies to N_b. Each weighted price is for transmission between the edge in question and the remote edge of the Internet, not just the remote edge of that provider. For full generality, there have to be four price weightings like this for every class of service at every inter-network interface, but the weights would take different values unless the neighbours were of the same status. The relationship between any two parties across the edge of their networks is split into prices for each class of service and each of these is further split into two prices for each direction, each of which are again split into 'half' prices that each party offers the other. Hence, we call this model 'split-edge pricing'.

Thus the payment for traffic in any one direction across each interface depends on the difference between the two weighted prices offered by the networks either side. In other words, no assumptions are made about who is provider and who is customer; this purely depends on the sign of the difference between the charges at any one time. Clearly, edge customers (N_c, say) have no provider status in the networking market. So, for all j, W_cjs = 0 and W_cjr = 0.

In Appendix B we analyse policies like 'only senders pay' or 'only receivers pay' using the model (by simply setting all receiving weights to zero or all sending weights to zero). Stability of a policy is determined by assessing whether one network would gain from a maverick policy. The results are summarised here.

'Only senders pay' or 'only receivers pay' are only stable policies if all providers agree to adopt the same policy, and none break ranks. As soon as one goes maverick, customers who are primarily receivers and those who are primarily senders migrate to different providers. Income appears to remain stable, but the source of the income switches from retail customers to interconnect causing the inter-provider link to become a bottleneck. Thus costs increase without any increase in revenue.

'Only senders pay' is also unstable where multicast is concerned. ('Only receivers pay' is all but meaningless for multicast.) To support an 'only multicast senders pay' policy, all domains have to trust each other to faithfully report receiver community size. In Appendix B we show that it is simple for a domain to lie about its local receiver community size to increase its profits. Proposed mechanisms such as 'EXPRESS count management protocol' [Holbrook99] suffer from this flaw. Solving this problem is unlikely to be successful without breaking the scalability benefits of receiver initiated IP multicast that ensure upstream nodes are unaware of downstream join and leave activity.

In contrast, 'both senders and receivers pay' is stable in both unicast and multicast cases. It also doesn't lead to inefficient network utilisation unlike the above cases. It is also possible to cater for different balances of predominant senders and receivers by weighting the sending price differently to the receiving price. For instance if there are a few big predominant senders but many small predominant receivers, the economy of scale in managing a large customer can be reflected in a lower sender weighting. Similarly, the inefficiencies of multicasts to small receiver communities compared to multiple unicasts can be discouraged by slightly weighting multicast sender pricing. The aggregation case is similar, with 'both senders and receivers pay' stable while the two other policies go unstable for the same reasons as for multicast, but swapped round.

If end customers want a different apportionment of charges, we have made the case for this being arranged end-to-end. The remainder of the paper concentrates on issues surrounding clearing. Also, at the end, various worked examples are given to illustrate how it would be achieved in practice. However, first, we introduce one further relevant issue - that of how a receiver can control its costs, if it can't stop itself being sent to.

6. Blame, liability and control

Ultimate sender blame presents a problem. In cases where the sender derives surplus value from a communication and the receiver derives less value than their provider charges, receivers are vulnerable to being exploited (e.g. adverts). Such cases are much rarer than it first appears, mainly because of confusions that can be cleared by considering the following factors:

• The value of the information isn't relevant when considering the networking service - only the value of moving the information - getting it to a useful place
• Often the value of moving information is transitory - getting it to a useful place to discover that moving it wasn't useful
• Often the value of moving lots of information is to get a small part of it to a useful place, but it isn't possible to know which part before moving it
• The cost of transmitting information is often far less than the cost of the effort of targeting which information should be transmitted
• Information in one direction often controls the flow of information in the other

7. End-to-end clearing

Fig 7.1 - 'End-to-end clearing' model

In the 'end-to-end clearing' model, the clearinghouse role deals with the end-to-end 'half-circuit' sharing (including the straightforward price differences between the two ends) leaving inter-provider accounting to be purely about wholesaling. The figure shows one end paying and follows example percentages of this money as they are distributed among the providers. Note that inter-provider money flows match the flow of networking service in the opposite direction across the same interface. This is the deliberate aim of the model, to ensure that bulk measurements at these boundaries can drive interconnect charges based solely on local conditions. It also allows each pair of providers to choose their own basis for metering independently of other arrangements at other interfaces.

There is nothing to stop providers or customers assuming the clearinghouse role, but the accounting information model needs to be based on a third party clearing system to allow for the most general case. To clarify, the paying customer may make payment:

• either to a dedicated clearing house
• or direct to the ISP at the remote end (the remote customer need only notify her ISP's payment interface to the payer)
• or even direct to the remote customer so that they can pay their own ISP

8. Iterative clearing

In this model, ISPs don't expect payment for all sent and received traffic to be made to all edge providers (Fig 8.1). Instead a customer might pay their own provider on behalf of both (all) ends as in the normal case for telephony and as proposed by Clark for the Internet [Clark96]. This alternative business model allows customers to decide into which end(s) payment enters the system, on a per flow basis. We shall call this model the 'iterative' model for reasons that will become clear as we go. The financial flows between providers in this model depend on at which ends payment is entering the system on a per flow (or per packet) basis. For some flows, there may even be proportional sharing of costs between the ends. For business model flexibility an accounting system would need a 'payee percentage' field - the percentage of the total cost to be paid by the customer at the end being accounted for. Usually it would be 100% or 0% in the typical cases of 'paid completely to local provider' or 'completely to remote'. The balance would be the remote end's payment. Note, though, that the perceived purpose of this model is the transaction efficiency when the local payee gets 100%.

If Fig 8.1 is compared with the end-to-end clearing model in Fig 7.1, both models end up with edge ISPs paid the same amounts on a half-circuit basis. The difference is merely in the route the payment takes from payer to payee. With 'iterative' clearing the payment follows the data path. Along the way, providers take their cut with two types of money sharing being mixed together:

• wholesale cut
• half-circuit sharing

Fig 8.1 - 'Iterative clearing' model

However, the amount deducted from the flow at each boundary doesn't match the level of service crossing that boundary. This can lead to complexity in the network, as there is pressure to design the network itself to reveal the apportionment of costs. This was why Clark was concerned about how much complexity would be added to the Internet to cater for arbitrary combinations of sender and receiver payments. This is also why international and interconnect on the PSTN have limited flexibility to arbitrarily apportion charges between the ends. Even 'free to sender' calls are blocked between a lot of countries because they don't yet have prices set or the interconnect accounting in place. Specifically, there are five points stacked up against the 'iterative clearing' model:

• As already pointed out, a 'payee percentage' field would have to drive inter-provider accounting, whether it was in accounting messages or packets. Otherwise the revenue of an edge ISP and its upstream providers would depend on a factor completely outside their control - to which end its customers chose to make payment. The 'payee percentage' field would therefore have to be trusted by upstream providers. To help prevent the field being tampered with, it would need to be signed by the remote ISP. How signed fields can be aggregated without losing the signature integrity would be a matter for further research.
• Still further complication might be introduced for some future applications if the share of payment between the parties wasn't fixed but depended on characteristics of the flow or other parameters only understood at a higher level - higher than the provider would normally be interested in.
• Worse still, the payment should ideally be split taking into account the current prices of all the edge providers who will eventually be paid. The only alternative (used in the international accounting rate system (IARS) for telephony) is for ISPs to agree compromise prices between themselves that average out price inconsistencies. This is what has been causing all the tensions in IARS as some countries liberalise earlier than others causing huge variation in prices around the world, between which no happy compromise can be found. This is difficult even for a system where every end to end path only passes through two international carriers at maximum, each pair setting compromise prices with each other. With eight ISPs on many end to end Internet paths, five typical [McCreary98] and considerable peer interconnection, it is likely that it will take longer to negotiate prices than the time available, thus leading to distortions to providers' supply and demand signals.
• Finally, because of the much longer provider chains typically found on the Internet, unacceptable delays will be introduced before the revenue arrives in the correct place. Any delay in clearing hugely increases the cost of the payment system, as extra trust mechanisms have to be invoked while the payment remains unconfirmed. These trust mechanisms have to be applied to the edge customers, not just the providers, therefore hugely increasing the total cost of the system.
• If multicast is to be catered for by iterative clearing (e.g. conferences), each provider needs to know how many ends they are serving locally, both to inform the person paying and check settlement. In contrast, with the end-to-end clearing model, if senders and receivers all pay, no-one needs to count ends. If clearing is desired by the ends, only the ends need to know how many ends there are to pay for - no-one needs to calculate how many ends are attached to each provider. Thus, for instance, if there is a charge to join a conference, this can cover the cost of paying each participant's communications charges as well as the content (each participant would have to declare their ISP when they join). The more who pay the host to join, the more there is to cover charges. Then the host can send bulk payments to the relevant ISPs, either directly or through a single clearer (see worked example below).

9. Example scenarios

9.1 Finding an end-to-end price

Whatever, the resulting intermediary could then be contacted to find the price being offered for the particular combination of ISPs. The same organisation would naturally take the payments and clear them between providers. The intermediary would also have to find out the prices being charged by the relevant edge-providers, which would represent its back-end costs. We assume the providers would be using tariff dissemination protocols such as in Rizzo et al [Rizzo99], Carle et al [Carle98] or Yemini et al [Yemini98] that could be listened to by the clearer as easily as by the edge-customers, particularly if transported over multicast.

9.2 Accounting and clearing with 'sender liable but local payment customary'

The following discussion is easiest to understand if we consider the accounts for one flow at a time. We assume that accounting is operating in near-real-time on a per-session basis, thus such an approach makes sense as a session consists of a set of flows known to at least a subset of the participants. Again, for ease of understanding, let us consider one incoming flow to one customer before we consider her outgoing flow. Note that two or more edge-charges are raised per flow depending on the number of ends, but we are focusing on one customer at one end (termed 'local'). For brevity, we will use feminine pronouns for the local customer and masculine for the remote customer(s).

If the local customer doesn't wish to pay her provider's charges for reception, she will present the account of her received flow to the clearer (discovered using the procedure in the previous section). She will identify the remote sender who she expects will pay. The clearer looks up the sender's ISP and debits its account, referring to the sender's address. When the sender's ISP settles its account with the clearer, it will deduct the amount from its account with the sender. The price used is the clearer's, which may or may not be identical to the local provider's price. If the sender is a large organisation, it might have an account directly with the clearer. The clearer also credits its account with the local ISP at the local provider's price, referring to the local customer. When this accounts settles, it will clear the local customer's debt with her local provider.

The sender cannot dispute the charge unless he has evidence that the receiver previously agreed to accept payment liability for traffic of this type from him. Purely for the clearer's information, the local customer may identify which records she believes the remote party expects to pay and which she is simply disputing. Thus despite the customary case being each end paying its own charges, the onus is on the sender to ensure it can prove this. In most cases, there is a relationship between the parties in a communication which will allow the sender to safely assume the customary case so that no receiver is expected to bounce its customary charges back to the sender. Where such trust isn't present, the sender might wish to ensure receivers have confirmed they are accepting the flow on the customary terms (where they pay their own end's charges). However, some ISP's may assume this liability and offer sender debt collection as a service.

We now move on to consider outgoing flows sent by the local customer. If she has evidence that the remote receiver has agreed to cover her local provider's charges for her sent traffic, she will present her account for the sent flow to the clearer. The mechanics of looking up accounts and debiting and crediting are as before. The receiver can only dispute this charge if he can prove the evidence saying he agreed to pay is invalid.

The local customer may optionally notify her local provider that she expects settlement for each flow will come from the clearer not herself. If the clearer never pays the local provider, the local customer remains liable to her own provider for the charges. If she has also already paid the clearer, she can ask the clearer for evidence that it has settled for the usage in question with her local provider. If it can provide the evidence signed by the provider, her liability to her provider is cleared. If it can't provide such evidence, it must return her payment so she will never have to pay twice.

This all seems very complicated, given it is per flow. However, in practice, settlement will be done in batch between each pair of parties as providers and clearers all have long term relationships with their customers. It is only the accounting that is per-flow. Indeed, even the accounting may be done in batches, but each batch will contain per-flow granularity of usage records. Also, it is clear that such reapportionment will only be cost-effective for flows where the value of the communications quality is higher than the cost of reapportionment. Examples would be long-lived flows, or collections of flows between the same ends where premium quality transmission service is used. Also, it should be recalled, that the clearing intermediary is merely a role. This role may be taken by one of the edge-ISPs or by one of the edge-customers, which removes the need for half the messaging.

Essentially, receipts are being traded much in the same way as employees claim travel expenses from their employer. This results in a scenario where the traditional telephone bill becomes an anachronism. Such a bill represents two commercial processes wrapped into one, which we propose should be separate. The first stage is reconciliation of all local usage records, whoever will pay. The second stage is agreement over who pays for which usage record.

9.3 Inter-domain multicast with heterogeneous QoS

We believe edge pricing allows enough flexibility to charge differentially for broad ranges of route lengths because it allows different charges for different administrative domains. Even if a single domain spanned the globe, if desired it could be divided into internal pricing domains to achieve the same effect.

We now go on to discuss how reapportionment of charges between the ends might work in this multicast case. It would be unlikely that anyone would volunteer to pay for all receivers however many there were, unless they had a prior arrangement with each receiver. For instance, if a conference organiser were offering to pay everyone's communications expenses, part of the charge for each participant to join the conference would most likely cover these costs. Thus, any number of participants could join but the host would still have all payments covered from income. The host might just allow enough in the conference charge to cover most prices of most providers and probably make a little profit to cover the risk. Other models might be possible. The host may only agree to pay each participant's charges up to a ceiling. Alternatively, the host may ask for receipts authenticated by ISPs and pay the exact charge of each ISP. Thus, the end-to-end pricing model allows full flexibility for reapportioning charges in both the multicast and unicast cases.

9.4 Phone to Internet gateway

Note that the end customer will see no difference if they rely on their edge network provider for all Internet telephony charging. This is purely an internal re-arrangement between ISPs. However, the customer could make these arrangements herself, if she desired.

Fig 9.1 - Clearing across a PIG

10. Limitations and Further Work

Also this paper argues the case for 'sender and receiver both pay', but it is not proven. The stability of inter-related ISP policies requires 'war-game' simulation as a step towards a proof. Further work is also required to exercise scenarios based on these models, through simulation and prototyping in order to fully work through the performance and security issues.

11. Conclusions

We have shown that the common case for apportioning value between the ends of a connectionless communication network is catered for if all users are charged for both sending and receiving. We have also shown that this is the most stable and efficient case, particularly for multicast and aggregation. It should therefore be used as the default in the 'split edge-pricing' model.

We have suggested that a new business model would be useful and more efficient to cater for the cases where there is a large discrepancy from this default in terms of value apportionment - large enough for it to be worth the cost of making a balancing transaction. This new model requires a new role in communications markets - an intermediary for end-to-end pricing and clearing. This new role could be conducted by existing ISPs or customers themselves, but there appears to be considerable added value, making this a viable business in its own right. It appears that this role is a threat to existing ISPs business. The role is one suitable for a purely financial processor using common e-commerce mechanisms with relatively low costs and the ability to take a share of the surplus value available on top of charge reapportionments. This role relegates edge ISPs into wholesalers for a potentially large class of Internet applications. The intermediary would become the retail face of the Internet in many cases.

Further, we suggest a subtle twist to the recommendation that customers should pay for both sending and receiving. We suggest this should be customary, but that ultimate liability for sending should lie with the sender. Disputes could then quickly be resolved through the end-to-end clearing role. This stems from the unavoidable fact that receivers can't avoid being sent to.
 

Acknowledgements

References

[Cairncross97] Frances Cairncross, "The Death of Distance : How the Communications Revolution Will Change Our Lives",  pub. Harvard Business School Press, ISBN: 0875848060, Oct 1997

[Carle98] Georg Carle, Felix Hartanto, Michael Smirnow, Tanja Zseby, (GMD FOKUS) "Generic Charging and Accounting for Value-Added IP Services", Technical Report GloNe-12-98, Dec 1998,  <URL:http://www.fokus.gmd.de/research/cc/glone/employees/georg.carle/>  (also presented at IWQoS'99 pricing workshop, Jun 1999)

[Clark96] David D Clark (MIT), "Combining Sender and Receiver Payments in the Internet", in Interconnection and the Internet. Edited by G. Rosston and D. Waterman, Oct 1996, <URL:http://diffserv.lcs.mit.edu/>

[Finlayson98] Ross Finlayson, Discussion at Third Reliable multicast research group meeting,  Orlando, FL, and following on the mailing list, Feb 1998 <URL:http://www.east.isi.edu/rm/>

[Herzog95] Shai Herzog (IBM), Scott Shenker (Xerox PARC), Deborah Estrin (USC/ISI), "Sharing the cost of Multicast Trees: An Axiomatic Analysis", in Proceedings of ACM/SIGCOMM '95, Cambridge, MA, Aug. 1995, <URL:http://www.research.ibm.com/people/h/herzog/sigton.html

[Holbrook99] Hugh W. Holbrook and David R. Cheriton, (Stanford Uni), "IP Multicast Channels: EXPRESS Support for Large-scale Single-source Applications", in proc ACM SIGCOMM'99,  (Sep 1999) <URL:http://www.acm.org/sigcomm/sigcomm99/papers/session2-3.html>

[ITU96] ITU, "The Direction of Traffic", ITU/Teleography Inc, Geneva, 1996 <URL:http://www.itu.ch/ti/publications/traffic/direct.htm> in brief chapter 3, Box 3.1 is extracted on-line: "Accounting rates and how they work", <URL:http://www.itu.ch/intset/whatare/howwork.html>

[ITU_RIARS] ITU "Reforming the International Accounting Rate System" <URL:http://www.itu.ch/intset/>

[Kausar99] Nadia Kausar, Bob Briscoe and Jon Crowcroft (UCL), "A charging model for Sessions on the Internet", in proc IEEE ISCC`99, Egypt, 6-8 Jul 1999, <URL:http://www.rennes.enst-bretagne.fr/~afifi/iscc99.html>

[McCreary98] Sean McCreary and kc claffy, "How far does the average packet travel on the Internet?", CAIDA, 25 May 1998, <URL:http://www.caida.org/Learn/ASPL/>

[MacKieVar92] Jeffrey K MacKie-Mason and Hal Varian, (UMich), "Some Economics of the Internet’, Tenth Michigan Public Utility Conference at Western Michigan University, March 25-27, 1993: <URL:http://www.sims.berkeley.edu/~hal/people/hal/papers.html>

[RFC2327] Mark Handley, Van Jacobsen, "SDP: Session Description Protocol", IETF RFC 2327, Mar 1998, <URL:rfc2327.txt>

[RFC2475] S. Blake (Torrent), D. Black (EMC), M. Carlson (Sun), E. Davies (Nortel), Z. Wang (Bell Labs Lucent), W. Weiss (Lucent), "An Architecture for Differentiated Services", IETF RFC 2475, Dec 1998 <URL:rfc2475.txt>

[Rizzo99] Mike Rizzo, Bob Briscoe, Jérôme Tassel, Kostas Damianakis, (BT) "A Dynamic Pricing Framework to Support a Scalable, Usage-based Charging Model for Packet-switched Networks", in proc. IWAN'99 Springer-Verlag, Jul 1999, <URL:http://www.labs.bt.com/projects/mware/>

[Shenker96] Scott Shenker (Xerox PARC), David Clark (MIT), Deborah Estrin (USC/ISI) and Shai Herzog (USC/ISI), ‘Pricing in Computer Networks: Reshaping the research agenda’, SIGCOMM Computer Communication Review Volume 26, Number 2, Apr 1996, <URL: http://www.statslab.cam.ac.uk/~frank/PRICE/scott.ps>

[Speakman98] Tony Speakman, Nidhi Bhaskar, Richard Edmonstone, Dino Farinacci, Steven Lin, Alex Tweedly and Lorenzo Vicisano, (cisco) "PGM Reliable Transport Protocol Specification", Work in progress: IETF Internet Draft, Jun 1999 (expires Dec 1999), <URL:draft-speakman-pgm-spec-03.txt>

[Yemini98] Y. Yemini, A. Dailianas, and D. Florissi, "MarketNet: A Market-based Architecture for Survivable Large-scale Information Systems", In Proceedings of Fourth ISSAT International Conference on Reliability and Quality in Design, Aug. 1998, Seattle, WA, <URL:http://www.cs.columbia.edu/dcc/marketnet/>

[Zhang93] Lixia Zhang (Xerox PARC), Stephen Deering (Xerox PARC), Deborah Estrin(USC/ISI), Scott Shenker (Xerox PARC) and Daniel Zappala (USC/CSD), "RSVP: A New Resource ReSerVation Protocol", IEEE Network. Sep 1993. <URL:http://www.isi.edu/div7/rsvp/pub.html>

[Zimm80] H. Zimmerman, "OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection", IEEE Transactions on , Vol 28, No. 4, Apr 1980, pp 425-432.

[Zull97] Chris Zull (Cutler & Co), "Interconnection Issues in the Multimedia Environment", Interconnection Asia '97, IIR Conferences, Singapore, Apr 1997 <URL:http://www.cutlerco.com.au/core/content/speeches/Interconnection%20Issues/Interconnection_Issues.html>

Notes

• RSVP receiver initiated reservation (RESV) messages
• pragmatic general multicast (PGM) [Speakman98] negative acknowledge (NACK) messages or the "lay breadcrumb" messages[Finlayson98] suggested in their place

Appendix A. Independence of logical classes of service

Fig A.1 - Split-edge pricing per class of service

However, because each network is managed autonomously, there may be disjoint mappings between classes of service in neighbouring networks (as allowed in diffserv). Such a case is shown between N_b and the right-most N_d, which uses one class of service where everyone else uses two. At such a boundary, W_dbs and W_dbr for the merged class appear from N_b's point of view to each be a pair of prices for each of its classes of service that happen to be identical. On the other hand, N_b might offer two different W_bdr prices and two W_bds prices to N_d for each of N_b's two classes. N_d would just see each pair as a single price that varied depending on the relative proportions of traffic coming from or going to each class. Therefore, even with disjoint class mappings, we need not concern ourselves with more than one class of service at a time.

Appendix B. Split-edge pricing model

We make the assumption that differences in length of routes or shapes of routing trees through any party's network will not produce cost differentials that are significant enough to be worth measuring and charging for. I.e, we assume the 'death of distance' [Cairncross97], or a 'black box' network routing assumption where a network's routing is hidden within its interfaces. This means we trust a network or inter-network of federated domains to find the cheapest route without end-system intervention or, put another way, that routing protocols approximate to a competitive market. If the route isn't truly the cheapest, we assume the discrepancy is so minor that the end-customer isn't concerned. Border routing policy distorts this considerably, but one of our long term motivations is to make most border-routing policy redundant, simplifying inter-provider interfaces using usage-charging instead. This also implies that internal network design inefficiency should be absorbed by providers in their overall pricing. For instance in current multicast routing, tree stability always takes priority over tree efficiency. Providers are free not to make this decision if they can design better multicast routing algorithms, but there is no need to expose internal cost differentials in external pricing (when they are purely for provider convenience in the first place). This is deliberately unlike any of the scenarios analysed in Herzog et al - the classic work on sharing the cost of multicast [Herzog95]. Herzog et al has a scenario where all receivers share the cost equally, but not where receivers are divided into sets based on provider domains and only charged equally per domain (edge pricing). Nor does it consider heterogeneous QoS. If some degree of distance-based pricing is required, we assume edge-address-based pricing mechanisms can be used without having to concern the end-systems with the route between addresses. But we believe even this is unlikely.

Fig B.1 shows a generic topology that will be used to illuminate the analysis. The general model and terminology have already been introduced in Section 5. We explained the scenario of a packet or flow being multicasted between inter-connected networks of various statuses relative to the one of interest and we explained the four price weights at any interface. However, we glossed over the details of the model (e.g. not saying what the weights were applied to). We will now correct those omissions.

Fig B.1 Split-edge pricing with heterogeneous QoS

The figure shows the classes of service, Q, set for each branch of the tree. Q may be confined to discrete levels or allowed to take any from a bounded continuous range of values, depending on the QoS mechanism. It is assumed that, wherever a packet is duplicated for multicasting, the multiple copies might each have different classes of service. Note that it has not been assumed that the branches all have different classes of service. This depends on the (independent) requirements of the ultimate ends of each branch. There need be no correlation between neighbouring network status and the value of Q for that branch. RSVP is an example of such a heterogeneous QoS scheme (diffserv has the potential to become heterogeneous, e.g. by setting the class of each branch based on the DS-bytes in the multicast routing packets or in the IGMP join packets from end systems or even using RSVP). The packet or flow being modelled could be data or signalling.

V represents some measure of the volume or size of the service consumed. It might be the amount of data in the packet or in a flow of similar packets for a certain time. It might be the time for which a reservation of a certain size is held. We simplify the model by requiring V to be the same for all branches of the tree. This is justified because a branch leaving the tree, a packet loss or a network filter can be dealt with as an alteration to the topology rather than allowing V to be heterogeneous. We shall define the 'nominal charge' function that N_b levies for the packet or flow as C_b(V,Q). This is a nominal charge because next we will describe how it is weighted to determine the actual charge for each different type of neighbour.

W_bas & W_bar denote the per direction weightings applied to the charge that N_b applies to N_a as shown at the highlighted interface between these two in Fig B.1. The third digit of the suffix denotes the direction of traffic that the weighting applies to; s being the weight for traffic sent into the provider, r for traffic received from the provider setting the charge. However N_a is also offering service to N_b. So similarly N_a weights its charge C_a with weights W_abr and W_abs. The first digit of the suffix of W denotes the network provider setting the charge being weighted. The second digit denotes the type of neighbour network provider to which this weighting applies. Often, we can consider scenarios where many of these price weightings are set to be either equal to each other or to be zero, but the formulae we come up with will allow fine granularity of price weighting for any scenario we might dream up in future work. We will initially experiment with blanket policies like 'sender pays all' but the formulae will allow consideration of more subtle scenarios where prices might be slightly unequal in the different directions, perhaps because of asymmetric access technology like xDSL.

To save drawing multiple diagrams, we will associate two integer direction flags with each packet. The forward direction flag, d, will be 1 if the direction is as shown in the figure and 0 if reversed. We define ð = (int)( ¬((boolean)d) ). That is, ð is effectively the negation of d (that is ¬d), but they are both integers, hence the need to cast d to boolean before negating it then casting it back to an integer. ð can be thought of as the reverse direction flag and is always the opposite of d. These two flags toggle on or off different terms in all the following formulae.

Thus, the networking surplus that N_b makes from N_a (also taking into account what N_a charges N_b)  is:

S_ba = d[C_b(W_bas,V,Q_t) - C_a(W_abr,V,Q_t)] + ð[C_b(W_bar,V,Q_t) - C_a(W_abs,V,Q_t)]  --- (1)

Although this is the general formula, for the scenarios we shall be analysing here there is too much generality to get a useful result. In practice, the following formula would be a reasonable specific form of the above:

S_ba = V[(dw_bas + ðw_bar)p_b(Q_t) - (dw_abr + ðw_abs)p_a(Q_t) ]             --- (2)

1. Both charge functions vary linearly with the volume of the service consumed. That is, for all i, j, k, z:
C_i(W_ijz,V,Q_k) = VP_i(W_ijz,Q_k)
where P_i is the price per unit V (which leads to charge, C_i).
2. Each provider has a single nominal charging function for all its customers and only varies the price for each status of customer about around this. We can then define a new set of weightings, w (lower case), which subsume the old weightings, W (upper case), to ensure all the pricing functions of one provider are the same. That is, for all i, j, k, z:
P_i(W_ijz,Q_k) = w_ijzp_i(Q_k)
where p_i(Q_k) (lower case) is a pricing function for service class Q_k to which all offers by N_i are linearly related.

For brevity, we define w_ijs = dw_ijs + ðw_ijr for all i,j. Therefore formula (2) can be written:

S_ba = V(w_basp_b(Q_t) - w_abrp_a(Q_t) )                           --- (2)

S_b = V[ w_basp_b(Q_t) + w_bcr(n_bcup_b(Q_u) + n_bcvp_b(Q_v) + ... ) + w_bdr(n_bdup_b(Q_u) + n_bdvp_b(Q_v) + ... ) + ...
           - w_abrp_a(Q_t)  - w_cbs(n_bcup_c(Q_u) + n_bcvp_c(Q_v) + ... )  - w_dbs(n_bdup_d(Q_u) + n_bdvp_d(Q_v) + ... )  - ... ]  --- (3)

Also, in practice, the class of service at the head of the tree need only be the maximum of the classes of service of any branch (due to the logic of either multicast or aggregation):

Q_t = max(Q_u, Q_v, Q_w, ... )                               --- (4)

 Unicast implies:       n_bjk = 1;   when j=c & k=u.    n_bjk = 0;   otherwise.
N_c being edge customers implies: w_cjz = 0;for all j, z.
and (4) becomes:        Q_t = max(Q_u)    = Q_u

S_b = V(w_bcs + w_bcr)p_b(Q_t)
     = V[(d+ð)(w_bcs + w_bcr)]p_b(Q_t)
     = V[(w_bcs + w_bcr)]p_b(Q_t); because (d+ð) = 1              --- (5)
S_c =  -Vw_bcsp_b(Q_t)                                   --- (6)

S_a = V[ (w_acs  + w_abr)p_a(Q_t)  - w_basp_b(Q_t)) ]                    --- (7)
S_b = V[ (w_bcr  + w_bas)p_b(Q_t)  - w_abrp_a(Q_t)) ]                    --- (8)
S_ca = -Vw_acsp_a(Q_t)                                   --- (9)
S_cb = -Vw_bcrp_b(Q_t)                                  --- (10)

With these simplified formulae for unicast, we can first show how the formula can be used to explore some possible unicast charging scenarios then consider their commercial implications. To help to connect together the scenarios, we will use numeric values for the weightings that could be used in realistic scenarios. To help further, weightings for all scenarios will be normalised relative to an edge customer, N_c, such that w_icz = 0, 1 or 2 for all i & z wherever possible.

The table gives the networking surplus (deficit) for each party in various scenarios. In the first scenario, as there are two edge customers, N_c, of the same provider, N_b, the edge customer surplus, S_c1, is the sender's and S_c2 is the receiver's when d=1.
 

Scenario (English)	Scenario (maths)		Sb/Vpb(Qt)	Sc1/Vpb(Qt)	Sc2/Vpb(Qt)
single provider, Nb, with edge customers, Nc, unicasting.			(5)	(6)	(6)
...and receiver pays all	wijs = 0 wijr = 2   any i,j		2	-2ð	-2d
...or sender pays all	wijs = 2 wijr = 0   any i,j		2	-2d	-2ð
...or senders and receivers pay equally	wijs = 1 wijr = 1   any i,j		2	-d - ð  = -1	-d - ð  = -1
two providers, Na & Nb each with an edge customer Nc, unicasting.		Sa/Vp(Qt)	Sb/Vp(Qt)	Sca/Vpa(Qt)	Scb/Vpb(Qt)
		(7)	(8)	(9)	(10)
retail & wholesale prices same...	wacz = wabz wbcz = wbaz   for either z
... and all retail prices identical...	wacz = wbcz   for either z
...and receiver pays all	wijs = 0  wijr = 2   any i,j	2d	2ð	-2ð	-2d
...or sender pays all	wijs = 2  wijr = 0   any i,j	2ð	2d	-2d	-2ð
...or senders and receivers pay equally	wijs = 1  wijr = 1   any i,j	d + ð  =1	d + ð  =1	-d - ð  = -1	-d - ð  = -1
...or Na only charges senders and Nb only charges receivers...  ... but all at the same price	wajs = wbjr = 2  wajr = wbjs = 0   any j	2d	2d	-2d	-2d
wholesale prices are half retail...	2wacz = wabz 2wbcz = wbaz   for either z
... and all retail prices identical...	wacz = wbcz    for either z
...and receiver pays all	wics = 0  wicr = 2   any i	d + ð  = 1	d + ð  = 1	-2ð	-2d
...or sender pays all	wics = 2  wicr = 0   any i	d + ð  = 1	d + ð  = 1	-2d	-2ð
...or senders and receivers pay equally	wics = 1  wicr = 1   any i	d + ð  = 1	d + ð  = 1	-d - ð  = -1	-d - ð  = -1
...or Na only charges senders and Nb only charges receivers...  ... but all at the same price	wacs = wbcr = 2  wacr = wbcs = 0	2d	2d	-2d	-2d

It can be seen that for intra-provider packets, the revenue is unaffected by whether senders, receivers or both are charged, but which customer(s) contributes to it, obviously depends on the direction of the unicast.

However, for inter-provider packets where peer providers charge each other as much as any edge customer, if both providers adopt a 'receiver pays all' or a 'sender pays all' policy, the revenue ends up always moving to the edge provider furthest from the customer paying. As long as each provider has a similar customer profile in terms of senders and receivers the net effect is that all providers make similar gains (and incidentally they could mutually agree not to charge each other with little change in their income - peering). Charging for only one direction has the benefit of halving the cost of measuring and accounting for both directions.

However, if all provider policies start as 'sender pays all', N_a might notice it has more receivers than senders. Let us assume N_a switches to charging receivers only, while N_b continues to only charge senders. A packet in the direction from N_b to N_a would result in each provider charging their edge customer for Q_t, but neither charging each other. A packet in the opposite direction would result in neither provider charging their end customers at all, but both nominally charging each other. This would, as one might expect, cause a migration of all predominant receivers to other providers like N_b and all big senders to N_a. This leaves all providers with very little edge revenue, but all just nominally charging each other similar amounts. Clearly this will not be tolerated for long as the edge-customers are exploiting the providers, all the traffic is being inefficiently and expensively funnelled across the inter-provider links and there is consequent pressure for all providers to reverse their policy. Changing the wholesale pricing policies will make no difference. If the retail policies remain imbalanced there will be little revenue entering the system. Thus neither all providers charging only for sending nor all charging only for receiving can be stable unless there is some industry-wide agreement as to which one to standardise around. If there is such tacit agreement, charging for sending seems preferable as it avoids the problem of charging for unsolicited receipt.

What this teaches us is that any extreme policy where either sending or receiving are offered at low or zero price encourages instability simply because local pricing doesn't match true local costs. Therefore, when end customers arrange themselves to their best advantage, providers suffer unless they collectively organise themselves, which is unlikely. On the other hand, all providers charging for both sending and receiving is also stable, and without artificial standardisation. If any provider breaks ranks and charges, say, only senders, receivers will quickly migrate towards it and senders away to the rest of the industry. Thus the most stable arrangement is for send and receive pricing to approximately match costs.

When the coefficients for multicast are brought in to the formulae (not shown above), this only strengthens the case for all ends being liable for their use of the network, whether sending or receiving. Here we consider single-source trees for brevity, but the argument is even stronger for shared trees. Today, multicast senders are being charged exorbitant rates such that only those with income from (or advertising to) large numbers of receivers become customers. In the longer term, 'sender pays all' will only be tenable if it is at a rate that reflects the number of receivers. However, if this problem is considered, the trust required to achieve a solution appears to put up a theoretical barrier to 'sender pays all'. The cost of an inter-domain multicast is spread throughout the tree. The cost to each domain is approximately proportional to the number of branches within that domain. The proximity of the tree's fan-out to its ingress into the domain determines the actual cost per branch. This in turn depends on how meshed the network is, which is usually a characteristic of the design of a whole domain (and if not, the internal design is under the domain's control). Thus, a 'leaf-domain' (one with only edge receivers and no downstream domains on the tree) can work out its cost for a certain number of receivers in its domain and report it to the upstream domain. This report is effectively a bill presented to the upstream domain, requesting a share of the income from the sender as it trickles down through the domains in the same direction as the tree. This upstream domain can collect similar 'bills' from other downstream networks and report the sum onwards upstream, eventually reaching the sender. Thus the head-end provider charges the sender the costs of the whole tree and has to pass on much of this income to meet the downstream 'bills'. Clearly, any domain can over-report its bill and make a profit. This is because the sender cannot determine the topology directly from its receivers without destroying the scalability benefits of multicast, which deliberately hides receiver activity.

It seems far simpler to apply the same argument as for unicast above and charge each receiver and the sender. The charges need not be identical for each, but the sender charge doesn't need to reflect the number of receivers. Where the tree crosses a domain boundary, each domain simply charges the other as one sender or one receiver. This ensures charging is completely distributed. There is not even a need to correlate together the receivers for one tree. All receivers are just usage-charged as they occur, with no need for co-ordination or totalling. As before, if the sender (or one receiver, or even a third party) wants to offer to pay for all receivers, this can be arranged end-to-end, rather than through the networks.