next up previous contents
Next: Multicast in the Internet Up: Internet Service Models Previous: Admission Control

Accounting

If a reservation involves setting aside resources for a flow, this will tie up resources so that other reservations may not succeed, and depending on whether the flow fills the reservation, other traffic is prevented from using the network. Clearly some negative feedback is required in order to prevent pointless reservations from denying service to other users. This feedback is typically in the form of billing. For real-time non-best effort traffic that is not reserved, this negative feedback is provided in the form of loss due to congestion of a traffic class, and it is not clear that usage based billing is required.

Billing requires that the user making the reservation is properly authenticated so that the correct user can be charged. Billing for reservations introduces a level of complexity to the Internet that has not typically been experienced with non-reserved traffic, and requires network providers to have reciprocal usage-based billing arrangements for traffic carried between them. It also requires mechanisms whereby some fraction of the bill for a link reservation can be charged to each of the downstream multicast receivers.

Recent work on charging[#!kelly!#] has proposed quite simple models of billing associated with multimedia traffic. A generalised model for pricing bursty connections (or flows in our context) was proposed in [#!burst!#]:

a * V + b * T + c

where V is the traffic volume at the minimum requested rate (can be zero) and T is the time at the average (measured) rate. The parameters a, b and c depend on the tarrifing scheme; e.g. peak rate, or IP subscriber's line rate, plus equipment rental. A minimum rate (e.g. MCR or controlled load) gives a volume related charge (constant also factors in providers' dimensioning) and a mean rate (e.g. for VBR, or guaranteed) gives a time related charge; mixes are allowed. Delay bound can be simply a boolean in the QoS API, which is easily implemented as the ToS delay preference bit in IP header; in most cases, this just selects a priority queue, although sometimes it selects a terrestrial over satellite route. For multimedia applications, which will probably initially use a service that approximates to a lightly loaded network, we get a similar charge model as for TCP, which may be surprising to people, but it has lots of nice practical properties: for example, a typical network that permits ``premium service'' TCP and Internet telephony, might implement the interface for the user as a single bit to select between normal TCP service (MCR==0), and controlled load TCP as well as telephony. The option for how to actually bill could be based on measured volume over time (the interval of an RTT is probably reasonable for both telephony and TCP based traffic), or might simply relate to the fact that most domestic users access the net over a dial up link, so the time related charge could be folded in there trivially, and the volume related charge based on measured mean rate - conveniently, the access line polices the peak rate trivially, since it is typically a modem+phone line or digital ISDN line, with a fixed line speed anyhow.

This is discussed further in chapter two.


next up previous contents
Next: Multicast in the Internet Up: Internet Service Models Previous: Admission Control
Jon CROWCROFT
1998-12-03