1
Pricing Internet Services Jon Crowcroft, Vicky Hardman, Dave Lewis Department of Computer Science, UCL, Gower Street, LONDON, UK j.crowcroft,v.hardman,
[email protected]
Abstract This paper describes a deployable simple pricing model for the Internet. To date, commercial Internet ‘data’ services have been charged almost exclusively via a flat-fee access-based mechanism. Customer demand is driving the Internet towards the provision of multimedia traffic, which needs a richer family of performance guarantees. The subnetworking technology is also maturing to meet the demand, and will soon be able to support these guarantees . In the light of these developments, the current limited tariff model must come under some scrutiny. This paper investigates service classes currently being specified for the Internet, and discusses how multimedia traffic can fit into one class to ease deployment of a charging model. A unified pricing model (suggested by Kelly) is confirmed as suitable for the Internet, and the mechanism can easily be extended to deal with more classes. The paper also suggests a time-line for the introduction of new pricing strategies that may be deployable.
1. Introduction This paper describes a deployable pricing model for the Internet. To date, commercial Internet ‘data’ services have been charged almost exclusively via a flat-fee access-based mechanism. Customer demand is driving the Internet towards the provision of multimedia traffic, which needs a richer family of performance guarantees. Real-time speech over the Internet (and video), at the out-set, appears to have vastly different characteristics and requirements to traditional ‘data’ applications, and so a number of different classes are being specified. The subnetworking technology is also maturing to meet the demand, and will soon be able to support these guarantees. New technologies, both at the Internet Protocol level, and in the underlying subnetworking transmission technology, (ATM bearer service classes, or Frame Relay's committed information rate), mean that guarantees for various performance parameters are now (or soon will be) feasible. In the light of these developments, the current limited tariff model must be replaced with one that can support multiple classes of traffic. This paper investigates service classes currently being specified for the Internet, and discusses how multimedia traffic can fit into one
2
class to ease deployment of a charging model. A unified pricing model (suggested by Kelly) is confirmed as suitable for the Internet. A two-tariff model can support priority traffic (Internet Telephony and premium TCP) is discussed as a suitable initial deployment scenario. Of prime importance within our design is that the Quality of Service (QoS) mechanisms, user interface, and signalling must be simple so that users can easily provide traffic characterisation information that is needed by the charging model. A further consideration is that cost recovery must be inexpensive; techniques for the aggregation of traffic monitoring and management are vital, even if this represents a trade-off, and savings in mechanism management are off-set by loss of network utilisation. The mechanism described can easily be extended to deal with more classes, and the paper also proposes that the tariff structure be allowed to vary depending upon the conditions in the network, and as a user’s requirements change. The paper suggests a time-line for the introduction of new pricing strategies that are easily deployable, and investigates how users should pay for guarantees - on-line charges, subscriptions or tokens. The paper begins with a discussion of the environment and the current perception of multimedia traffic over the Internet, and identifies how this traffic can be thought of as belonging to a single class (controlled load). The next section describes how the model can easily be expanded to deal with more than one class, and proposes some additions to the model for use over the Internet. The penultimate section presents the time-line for deployment of new services with their tariff models, and the paper concludes with a summary.
2. Background The Internet and Service Providers The Internet is made up of a very large number of heterogenous inter-connected networks. These are clustered into groups, and managed by Internet Service Providers (ISPs). Individual networks consist of a number of routers, inter-connected by links. Links may be multi-point LANs, MANs, or switched/leased point-to-point bearer ‘circuits’, such as those provided by ISDN, Frame Relay or ATM. Routers are IP packet forwarding devices that use FIFO queues on both the input and output links. Definition of a Traffic Flow Data transfer across the Internet is connectionless - information is sent in packets (datagrams), each of which is routed independently. However, it has become common to refer to a sequence of packets belonging to one application as a flow. Packets that belong to a single flow may be routed via different paths within the Internet, and this can lead to mis-ordering of
3
packets at the receiver. Reliable delivery is also not guaranteed, as overloaded routers will throw away excess packets. Internet Protocols Internet applications can use the Transmission Control Protocol (TCP) to provide a transparent end-to-end reliable service across multiple sub-networks. TCP also has some flow control mechanisms built into the protocol, and so applications that do not require this functionality (such as one shot interactions e.g. directory access), commonly use the user datagram protocol (UDP) to provide a far more light-weight service. Real-time applications (such as Internet Telephony) also use UDP, since they don’t require reliable delivery; retransmissions would arrive too late to be of use. Internet Telephony also commonly uses the IETF standard real-time protocol (RTP) [RTP] on top of UDP to provide facilities such as time-stamping for accurate play-out at the receiver. Charging in the Current Internet Environment Some subscribers are charged for Internet access via a fixed-rate tariff. The tariff is based on the line capacity from the customer premises to the provider's backbone. Dial-up users may also incur additional charges for the call time, which are based on both local PSTN call charges, and extra charges to prevent modem ``hogging'' at a provider's access point. Despite these extra call-related charges, the model is essentially one of a flat fee. This simple flat-fee model is extendible to inter-ISP domain traffic, where a user may wish to access information services on other ISP backbones. In this case, it has been assumed that the ISP-ISP traffic in each direction is symmetrical, and inter-provider settlements are therefore avoided. An Internet user typically runs a small set of the following:
•
interactive remote terminal access (telnet/rlogin)(TCP/IP)
•
electronic mail (SMPT/e-mail, including multimedia mail)(TCP/IP)
•
browsing/searching World Wide Web servers (Mosaic/Netscape)(TCP/IP)
•
Internet Telephony (RTP over UDP/IP)
Current traffic statistics indicate that the last two items in the list (web access and Internet Telephony) account for most of the traffic, the most prominent consumer currently being Web access [Desktop]. The Internet has traditionally provided a ‘best-effort’ service, which is typically implemented as a FIFO queuing system with no admission control. In the past, Internet links were mostly LANs (such as Ethernets), and leased lines were used to provide wide area
4
connectivity. In this network architecture, LANs had excess capacity, and leased lines were the main potential bottlenecks. End-to-end protocols (such as TCP/IP) were developed for ‘data’ applications to share out the limited wide area capacity equally amongst users. Current Telephone Network Charging Models In contrast to the Internet flat-fee charging model, telephone network billing mechanisms charge for each call on a duration and distance basis. Billing ‘records’ are regularly generated throughout the duration of the call, and dumped to disk for off-line processing. This charging mechanism carriers a significant cost overhead: billing records must be analysed, complex voice exchange software must be well maintained, and call charges must be collected from users. New Internet Charging Models In the Internet community, the following terms are being used in discussions of traffic accounting:
•
metering Metering is performed at a router (typically an ISP's edge router), and provides usage statistics at the packet level
•
class Class is the definition of a flow's performance requirements. ‘Data’ applications such as a telnet connection may need good end-to-end reliability, but be relatively tolerant to delay variations. Conversely, ‘real-time’ applications, such as Internet telephony, may require tightly-bounded delay variability, but are more tolerant of occasional packet loss
•
price Access charges are based on the service class and usage of the flow
•
tariff A tariff is the definition of a cost of a service described in terms of usage parameters
•
tokens/subscriptions Not all charging is useage based; it is possible to pre-pay for a level of service. Such a pre-paid scheme could be implemented on a permanent basis (subscriptions), or by means of a token - when the user wishes to have a guaranteed level of service for a period of communication, a token is used to pay for it
Most new networks (ISDN, ATM etc.) have been designed to carry a variety of traffic, for which a number of profiles or service classes have been specified. ATM service classes are quite complex, and include unspecified bit-rate (UBR), available bit-rate (ABR), variable bit-
5
rate non real-time(VBRnrt), variable bit-rate real-time (VBRrt) and continuous bit-rate (CBR) [atmq]. Bandwidth reservation in the Internet is also being developed, and sophisticated services are being specified that will be deployed by future Internet Service Providers. The model for the introduction of integrated services is based around a signaling system - a fairly revolutionary addition to the Internet architecture. The Reservation protocol (RSVP) has been designed to facilitate signalling, and the specification also includes, a template for service classes [rsvp,reserve]. The range of service classes consists of the following (from the specifications on integrated services internet classes [refs]): guaranteed, controlled load, predictive, controlled delay, and committed rate.
•
Guaranteed This class is very similar to the CBR service specified for ATM. It is intended for use by real-time traffic
•
Controlled Load The controlled load class provides end-to-end behaviour provided to an application by a series of network elements providing controlled-load service tightly approximating the behavior visible to applications receiving best-effort service *under unloaded conditions* from the same series of network elements
•
Predictive The predictive class provides end-to-end behavior provided by a series of network elements that conform to this class and provides three levels of delay control. Each service level is associated with a fairly reliable delay bound, and almost all packets are delivered within this delay bound.
•
Controlled Delay The controlled delay class provides three levels of delay control; network elements, when overloaded, are required to control delay by denying service requests. However, there are no quantitative assurances about the absolute level of delay provided. The controlled delay service is designed for service-adaptive and delay-adaptive applications.
•
Committed Rate The committed rate class provides applications with a firm commitment from the network, that at a minimum the transmission rate they requested is available to them at each network element on their path. The commitment of a given transmission rate by a network element is not associated with a specific delay guarantee, but requires that network elements perform admission control to avoid over-allocation of resources.
The equivalence of Internet classes to ATM Bearer Service classes is non-unique (i.e. there is more than one possible mapping from these to ATM, and in the ISSLL work, some of these possibilities have been explored for guaranteed and control load [map].
6
Each Internet link is commonly used to multiplex many flows, and guarantees for a particular flow’s share of the capacity (according to class) are accomplished at the IP level by priority output queues in each router. Where routers use links from a switched service, QoS guarantees may be provided by the underlying network; the two cases that are common are Frame Relay and ATM. Frame Relay is normally used to connect edge routers from one sub-network to those of another sub-network. Frame Relay links provide multiplexing at the data-link or router level, so the QoS is provided for aggregate flows. The IP router must be enhanced beyond a FIFO model to provide a choice of services to individual IP flows. ATM provides multiplexing at the Physical layer or cell level, which means that it may be possible to match IP level flows to underlying ATM virtual circuits, or at least IP flows to service classes. Queuing Models There are two relatively new queuing models that are being deployed in the Internet. Weighted Fair Queuing (WFQ) [wfq] has been developed for real-time traffic, and Random Early Drop (RED) [red] has been developed for non-real time traffic. Weighted Fair Queueing (WFQ) is an extension to Fair queueing. Fair queueing is a mechanism for providing a set of traffic flows with a guaranteed minimum share of an output link. Fair routing comes about because of round-robin scheduling allocation of the link to each source. If a source is not ready to use its share, then the capacity is used by the next source that is waiting. WFQ makes better use of the link than simple time division multiplexing, since weights are assigned to the sources to distribute the link’s capacity in desired quantities. WFQ has been shown to have predictable delay properties in Parekh's work on Generalized Processor Sharing [parekh]. Random Early Detection or Random Early Drop (RED) is a technique to improve delays and fairness in packet switching beyond that possible with a system of simple FIFO queues. Under increasing load conditions, a RED queue drops packets with a uniform random distribution. This mechanism is therefore able to apply greater loss probability to the main contributers to the overload.
3. The Myths and Realities of Acceptable Internet Provisioning The advent of new multimedia capable networks has initiated debate about accounting models for such traffic. The current confusion is based on the simple, but misleading view that
7
the two types of traffic can be thought of as exclusively distinct, when designing charging mechanisms. The current perception of these two types of traffic is judged to be as follows:
•
‘Data’ ‘Data’ is elastic - it can be successfully transferred at any data rate. In a network, a suitable congestion control algorithm implemented end-to-end by each application can be based on a ‘linear increase, exponential backoff’ feedback loop. TCP was originally not elastic, and the TCP congestion avoidance scheme [jacobsen] was not part of the basic services of the Internet at all. Existing ‘data’ applications had to be encouraged conform to the scheme (or come close to conforming), and this took a lot of effort. When the Internet carried only data applications, a ‘flat-fee’ charging mechanism was suitable, given the behaviour of TCP/IP during congestion. A graph of overall network Utility versus Load for TCP traffic is always increasing (concave) no matter how may extra users you add; even an infinitesimally small data rate for each user still represents a benefit. This means that ISPs can buy fixed-rate transmission capacity from network providers, and re-sell it as a statistical multiplexed service to IP users, without having to worry about any restrictions on the leverage/re-sell ratio.
•
Real-Time Traffic Real-time traffic, such as PSTN speech, has traditionally been provided with a fixed transmission rate, and a small round-trip delay. Internet telephony ostensibly also requires a fixed transmission rate, and small end-to-end delay, but packet speech also requires a small delay variance [rat1]. If the network cannot provide these stringent delay requirements, then the resulting audio is unusable. The use of silence suppression enables multiple audio connections to share a fixed bit-rate link, but only at the expense of incurring packet loss (this technique is similar to the PSTN call multiplexing on international links, and it suffers from similar problems; parts of words are lost). The utility curve for Internet Telephony is therefore convex, and asymptotes to some fixed re-sell multiple of the underlying leased transmission capacity.
8
The above distinction is a myth, and the realities are much more subtle:
•
Data Rather than being truly ‘elastic’, the current TCP/IP congestion avoidance algorithm has a minimum bit-rate - less than 1 packet per round trip time means the TCP throughput feedback mechanism is no longer present. Measurements from very congested links show that TCP traffic from multiple sources encounters random synchronisation effects. This leads to instability, and a tremendous reduction in network utilisation (up to 90% of data packets are lost due to competition with re-transmissions). Even in the absence of network instability at high congestion levels, users do not want an infinitesimally small data rate - a reasonable interactive response is required. For example: A typical WWW page (the most common application using TCP) takes 11-13 packets to retrieve (including protocol overheads). If interactive performance is taken to mean around 1 second per page, then this amounts to 16kbps. The above means that the utility curve is not concave, but convex.
•
Real-time Traffic Internet audio uses speech compression algorithms (as well as silence detection) to increase the number of flows that can share a link. Speech compression is used to reduce the packet rate, while keeping the packet size approximately constant; this increases the end-to-end delay - samples for 1 packet all have to be collected before the packet can be sent. The speech compression level can be changed at will, and adaptive buffering at the receiver accommodates a wide range of delays. Some of the more sophisticated Internet voice applications (such as Mbone audio tools RAT [rat2] or vat[vat]) use the Real-time control Protocol (RTP) [rtp]. Associated with RTP is a session level control protocol (RTCP), that provides statistics communication facilities to session participants. RTCP incurs a low fraction of the session bandwidth (about 5%). Internet telephony tools are evolving towards being adaptive applications. When loss occurs, the rate should back off (in a similar way to TCP/IP), but there is a minimum bit-rate for audio that is useable (in practice about 4kbps, but possibly 16kbps if ‘toll’ quality speech is required). When conditions over the network ease, then highre bit rates should be transferred, not only to transmit at ‘toll’quality again, but alos to reduce the end-to-end delay. The above means that audio (and video [mccanne]) can be made to fit the same
9
class as TCP/IP. Multimedia traffic has a range of source characteristics, but there is no reason for ISPs to be any more suspicious of IP-based audio than of classic TCP-based applications. Essentially the utility graph for both data and real-time traffic is very similar (see also [mcanne] for information on video), and one charging model could be used for both types of traffic. While it might seem reasonable to assume that the required Internet class is one of committed rate, the controlled load class offers approximately the same performance guarantees, and maybe cheaper, and maybe easier to implement in some sub-networks.
4. A Tariff Structure for the Internet Since TCP traffic and Internet Telephony require similar guarantees from a network, a suitable charging model would consist of a single set of measurements for all traffic types. Related Work Recently, there has been a series of proposals for the pricing of Internet traffic. Varian and MacKie proposed two interesting approaches, namely pricing for congestion [var1], and an auction for capacity [var2]. In contrast, Shenker [plea] argued that a pricing system should not rule out any particular pricing policy, and that congestion pricing may not be a realistic option in practice. This means that edge-pricing, usage-pricing and flat-pricing form a spectrum of usage-constrained pricing policies. Consistent with the above, Kelly proposed a generalised model for pricing bursty connections (flows in our context) [burst]: a*V + b*T + c Where: •
V is the traffic volume at the minimum requested rate (can be zero),
•
T is the time at the average (measured rate)
•
a, b and c depend on the tariff selected (e.g. peak rate, or IP subscriber’s line, plus equipment rental)
:A minimum rate (e.g. MCR or controlled load) produces a volume-related charge (the constant can be used to factor in the providers' network dimensioning). A mean rate (e.g. for VBR, or guaranteed) produces a time-related charge. Traffic mixes are allowed. This form is the simplest scheme to provide feedback to the user. It is in her interest to specify the right tariff, since this will result in the right price, at the same time as allowing the network provider to optimize services for a set of users. In the Internet, the user could adjust the tariff selected at quite frequent intervals (compared with a circuit switched network), adapting to changing
10
conditions. Nevertheless, over a short time frame, the volume and time related elements of the price allow the network to trade of throughput and delay through relevant buffering. This is essentially the concept of equivalent bandwidth. We discuss below, whether a user in this equation represents a single source application, host, site network, or even ISP or Intranet. There is a cost of accounting that is a function of the granularity of accounting, and this must be subtracted from the revenue made above. A balance between feedback to the user, and feedback to the provider will find the right operating point.
5. A Unified Pricing Model for the Internet Metrics to be Collected Based on Kelly’s Unified Pricing Model, the metrics that need to be collected are the measured volume over time (time related charge), and the measured mean rate (the volume related charge). As most users typically access ISP services via modem and PSTN line or ISDN connectivity, this provides the beginning and end point between measurements pertaining to that users usage should be measured. To a first approximation the mean and minimum rates measured over such a period provide the figures needed for this pricing model. The cost of the accounting system should consequently be minimal, since very little information needs to be logged to determine the typical mean use over time of a ‘call’. Initial Deployment Having shown that the quality of service a user requires from a TCP/IP connection is very similar to that expected of controlled load Internet Telephony, then the initial deployment of a charging mechanism for the Internet could use a single charging model for both types of traffic. For example, a typical network that offers ‘premium service’ TCP and Internet telephony as one class, might implement the user interface as a single bit. The bit selects between the normal TCP service (a minimum committed rate of 0), and a controlled load service that can be used by both TCP applications and telephony. A quality of service single bit choice from the user can be implemented in each datagram as the Type of Service delay preference bit in the IP header. When IP datagrams (that carry this preference bit) arrive at routers, the datagram normally will be put on a priority queue, which is emptied to outgoing links in preference to a low priority queue. A Wider Choice for the User After initial deployment, the charging model can be extended further to provide more service classes. A number of quality of service bits can then be used to distinguish user
11
preferences for delay, throughput and error. QoS routing dictates that a route is selected using the throughput preference first (measurement-based admission tests can be used to match users traffic to links from the underlying network - perhaps a subscribed service), and then delay and error guarantees second, since they are dependent variables [crowcroft]. In these circumstances, recordings for the mean and variance of these QoS parameters are unnecessary - if every user chooses an appropriate throughput rate for the network (and is policed to match it), then the delay and delay variation experienced by each flow are very small effects, usually due to the sources own burstiness, and so there is no need to have them controlled. Figure 3 illustrated how TCP/IP and real-time traffic could be thought of as being in the same class. Extending the system to include more classes results in a number of curves between the two extremes; some curves will be flatter (more like TCP/IP) than others. The curves could then be split into bands, where a band represents the traffic in that class. Kelly’s charging model is still suitable for all the classes, since they are all still roughly the same shape. Allowing the Tariff to Vary Kelly’s unified charging model allows a user to vary the tariff chosen during a call. Kelly’s argument assumed that a variation in tariff resulted in a new connection being set-up, and so levied a set-up charge. The statistical sharing nature of the Internet means that if a flow changes its requirements, this does not necessarily result in a new connection being set-up. This means that a user can change the flow’s requirements at will. If a user can change the flow’s requirements, then the network can change the service contract (and the tariff structure), depending upon conditions over the network. So, if the user wants to vary, then feed-back can be given to the user to allow an informed choice. For example, if the tariff has a delay bound, then the feedback can be based on "money" - i.e. if no more money is paid then network congestion will result in the delay being increased or the throughput lowered. If the user’s traffic is not sensitive to delay, then increased congestion will cause the traffic to be buffered until perhaps loss occurs. This assumes that loss is loss done through a fair scheme (e.g. RED, not FIFO). From Accounting to Billing Measured rate for delay sensitive traffic maps it to a template or expected rate for a range of applications - if it isn’t a good match (remember there are a whole spectra of possible equivalent bandwidth results for a given rate + burst source!), then either bill lower and loss, or bill higher and ask for more money. However, this can be reflected in the architecture for accounting and billing quite a few different ways:
12
•
The basic choice for the user is: Subscription versus tokens versus on-line charges.
•
At the internal interface (NNI in ATM language) between ISP and ISP, we can envisage transferring individual charges. We can also envisage transferring some notion of collective quality, e.g: in phone nets, call blocking probability; in the Internet, packet loss or delay probability; with RSVP, reservation rejection probability, or for a high risk ISP, breach of contract for QoS (e.g. exceeding negotiated CDV, or packet loss delay contract, or minimum cell or packet rate for an agreed connection).
6. Use of Address Allocation in the Charging Mechanism One way we could envisage implementing priorities would be to sell addresses that are treated differently in the routers or are routed over links which are deliberately shared out to fewer sources. To do this, we would need routers that could route based on source address (as well as destination), or we would need to replicate the routing state for sources that wished to use a priority based on such a scheme (or both!). An address might correspond to a range of services subscribed to (not just to one single one), and those services might have a limited lifespan (token limited to a maximum usage as a percentage of one's access line speed per 24*7 for example). This provides spatial and temporal aggregation of "reservations" again. Some routers now implement Weighted Fair Queuing (WFQ) on a variety of input, typically, by application, and by input port on a router - it should be possible to partition up the address space so that a number of net/host from a site arrive at a bottleneck router VIA a different port (through policy routes making the default route taken by normal addressed packets not visible, for example). it would require leaf routers to participate in the scheme though. Note, however, that some WFQ implementations are limited in the range of mappings from traffic class to weighted queue. In general, WFQ can be implemented to a very fine grain of allocation quite efficiently, however. One problem with this scheme is that routers don't currently do WFQ on source address, however, adding source address as a possible hash field to get to a WFQ is pretty simple. Failing this, assuming that outbound traffic is subject to the same queue on the return path, (at least for Web access this is true), then basing it on destination at the far end will also sort of approximate to the same result, except for one important class of traffic - Mbone. Address Space and router memory are both running out - this scheme will only work if we can reclaim addresses - we can make it a precondition of getting "priority addresses" that a university/customer renumber all their systems to allow the provider to regain some breathing space.
13
A user organisation could purchase address space that is treated with priority access, is at liberty to re-sell use of that space in lots of ways. One example could be that inside a university, the addresses in that space are allocated through the Dynamic Host Configuration Protocol [dhcp], and users get some number of tokens that are time based, for how long they can use part of the address space. Another example might be a public Mbone phone box where coins are used to gain access to an address. Other schemes are possible. Clearly, if we use an address space that gives guarantees at one bottleneck (e.g. between the first and second hop ISPs) there is no guarantee that it works on the next hop too. However, there is an incentive that can be created between ISPs (and between bottle-neck providers, or BNPs as we might term them) - lossy BNPs can be billed by guaranteeing ISPs, for failing to match the service agreement. This could form the basis for settlements very easily. The service contract should be stated, perhaps using the same parameter set as defined in tspecs and rspecs in RSVP, and through the same Policy Modules, so that we have a deployment scheme for RSVP too. The Internet has very good aggregation of information for many purposes - address aggregation (and name aggregation, and route aggregation, with ``CIDRized'' [cidr] hierarchical IP addresses) all make the net highly deployable and cheap to manage. We would like subscriptions to be aggregateable - clearly address based subscriptions would work fairly well in this regard.
7. Related Issues The Cost of Charging Keeping the cost of charging down is a good idea - this is why subscription based schemes seem to be sensible - we can see that they ought to scale only slightly worse than the current flat fee system. We can implement on-demand reservations by dynamic address allocation, instead of via a new protocol, too which can then be locally accounted - this then has the nice property of completely distributing the onus of charging and authentication, and leaving policies for how users obtain a priority up to the edge networks instead of the center. Archive and Mirror Servers Archive and mirror servers often confuse debates about charging. However, if we model a mirror or archive or Web Cache server as an ISP, we have a good handle on how to include them in our billing model - we simply regard traffic between a server and a subscriber
14
to a remote ISP as transiting the ISP that sponsors the server. However, competitiveness between ISPs, information providers, and new style providers who carry both service levels. may be harder to ensure.
8. Conclusion In this paper, we have discussed current and future pricing models and mechanisms for Internet services. We have argued that, with appropriate aggregation techniques, the model proposed by Kelly for bursty flows is relevant, and indeed the right model for Internet pricing, provided that the cost of the granularity of the accounting mechanisms are taken into account. Further, that the Internet has emerging technology to implement the traffic service differentiation necessary a priori to make pricing applicable. We believe that all applications, in a real commercial network world do in fact require traffic service contracts, irrespective of the apparent arbitrary elastic nature of the TCP protocol upon which many non-real-time applications are based. We have proposed one simple deployment mechanism based on address (re-)use, but many others, including explicit signaling of service requests through RSVP are also possible, When traffic flows are aggregated, it will be necessary for networks to offer some evidence of fair allocation of resources within an aggregation. Fairness is a difficult topic for best effort traffic, and this is clear from the debates about FIFO versus RED [red] queueing schemes in IP routers, or ABR versus UBR support in ATM networks, for TCP type traffic support [abrubrtcp].This remains a research topic.
9. Bibliography [abrubrtcp] Hongqing Li, Kai Yeung Siu, Hong Yi Tzeng, and Chinatsu and Ikeda, "A simulation study of TCP Performance in ATM Networks with ABR and UBR services," in Proceedings of the Conference on Computer Communications (IEEE Infocom) [atmq] The ATM Forum, "ATM Forum Traffic Management Specification Version 4.0" [burst] Kelly, F.P., "Charging and Accounting for Bursty Connections", in Internet Economics, Lee W. McKnight and Joseph P.Bailey, MIT Press, 1996 [crowcroft] Crowcroft, J., Wang, Z., Smith, A., Adams, J., “A Rough Comparison of the IETF and ATM Service Models, IEEE Networks, Vol 9, No.6, July 1995 [cidr] Hans Werner Braun, Peter S. Ford, and Yakov Rekhter, "CIDR and the evolution of the Internet Protocol," in Proceedings of INET 93, (San Francisco, California), Internet Society, Aug. 1993 [dhcp] R. Droms, "Dynamic host configuration protocol," Request for Comments (Proposed Standard) RFC 1541, Internet Engineering Task Force, Oct. 1993
15
[jacobsen] Jacobsen, V., “Conjestion Avoidance and Control”, Proc. SIGCOMM ’88, vol 18 No 4., August 1988 [map] Marty Borden, Bay Networks, Mark W. Garrett, Bellcore. "Interoperation of Controlled-Load and Guaranteed-Service with ATM" (draft-ietf-issll-atm-mapping00.txt) [mccanne] McCanne, S., Jacobsen, V., Vetterli, M., “Reciever Driven Layered Multicast”, ACM SIGCOMM ‘96 [parekh] Parekh A.K., Gallager R.G., “A Generalized Processor Sharing Approach to Flow Control in Integrated Service Networks - the Multiple Node Case”, in IEEE-ACM Transactions on Networking 1994, Vol. 2, No. 2, pp 137-150. [plea] Agenda S. Shenker, D.Clark, D.Estrin, S.herzog, “Pricing in Computer Networks: Reshaping the Research”, in Internet Economics, Lee W. McKnight and Joseph P.Bailey, MIT Press, 1996 [red] Floyd, S., and Jacobson, V. Random Early Detection gateways for Congestion Avoidance: Part 1, Part 2, Part 3, Part 4, Part 5. IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413 [reserve] R. Braden, L.Zhang, S.Berson, S.Herzog, S.Jamin, ”Resource ReSerVation Protocol (RSVP)”, Version 1 Functional Specification, draft-ietf-rsvp-spec-12.txt [rat1] Hardman, V., Sasse, M.A., Kouvelas, I., “Successful Multi-party Audio Communication over the Internet”, University College London, Department of Computer Scince research note RN/96/60 [rat2] Hardman, V., Kouvelas I., Sasse M.A., Watson A., “A Packet Loss Robust-Audio Tool for Use over the MBone”, University College London, Department of Computer Scince research note RN/96/8 [rsvp] Zhang, L., Braden, R., Estrin, D., Herzog, S., and S.Jamin, "Resource ReSerVation Protocol (RSVP), IEEE Network, 1993. [rtp] ‘RTP: A Transport Protocol for Real-Time Applications”, Audio-Video Transport WG, RFC 1889 [var1] Jeffery MackieMason and Hal R. Varian, "Pricing congestible network resources," tech. rep., University of Michigan, Michigan, USA, July 1994. [var2] Jeffrey K. MacKieMason and Hal Varian, "Pricing the internet," in Public Access to the Internet (Brian Kahin and James Keller, eds.), Boston, Massachusetts: ACM, May 1993. version of February, 1994. [vat] Jacobsen V., “VAT Manual pages”, Lawrence Berkeley Laboratory (LBL), February 1992. Alos http://www-nrg.ee.lbl.gov/vat/ [wfq]
