Next: Multicast in the Internet
Up: Internet Service Models
Previous: Admission Control
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: Multicast in the Internet
Up: Internet Service Models
Previous: Admission Control
Jon CROWCROFT
1998-12-03