I posted the following to nren-discuss and it sank without trace.
Nobody said they liked it and the one person who said they didn't
like it thought that it was a per-packet charging scheme which it
explicitly isn't.

I'd be particularly interested in the reaction from commercial network 
providers as to how this model would suit them and their customers.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

As Barry Shein points out, the problem with the current charging 
system is that the connection cost is inflated to cover backbone
costs. Backbone costs in turn are inflated by small groups of heavy
users. This situation is getting worse and is preventing Internet
technology having the coverage we would all want for it.

Here is a 3 level scheme to address this problem. It is a fixed
price scheme: no packet charging.

1. Packets with QOS set to "no-priority" are regarded as ballast. They
are queued and transmitted only when there is spare resource to do
so. Backbone links are never upgraded just because no-priority packets 
are being dropped. 

By default a connection to the Internet only entitles you to send
and receive no-priority packets (unless someone else is paying: see
below). This means that your connection to the Internet contains no
extra charge to cover upgrading the backbone. Chances are that using
no-priority packets will give poor connectivity to distant destinations, 
but connecting to other sites in your local area will often be ok.

2. At the other extreme some traffic, e.g. real-time sound, needs flows 
with guaranteed bandwidth. The obvious solution here is to add charging
information to the flow set-up protocol. This is quite a familiar area
since it is basically the way the phone network works today.

3. Between those two are priority connection-less packets. These should
be handled by the user paying a premium to allow him to send priority
packets at some rate. For example you might get a T1 link and also pay 
to have 64Kb worth of priority packets. A leaky bucket algorithm at your 
connection point will keep you to that limit over some time scale. [The
leaky bucket scheme wouldn't drop packets just reduce their priority:
perhaps to a level between the no-priority level and the full priority
level].

Actually you might pay different amounts for local priority, intra-national 
priority and international priority packets, or perhaps it would be done 
by buying the right to priority packets from different backbone providers.

At any rate the point is that pricing for priority bandwidth would be
structured in such a way that the backbones can be upgraded to avoid
any significant (sustained) dropping of priority packets.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

There are problems with any charging scheme that automatically charges 
packets to the sender or to the receiver. So we need to have some 
support for "reverse charging". I used to think that this required 
some sophisticated scheme. But on reflection I now think that all 
that is needed is 1 bit.

The "Who to Charge" bit
-----------------------

The who-to-charge bit is 0 if the packet sender is to be charged and 1 
if the packet's recipient is to be charged.

Clearly the sending host has to set the bit. The sending host should
only do this when providing a service to the recipient. Examples include
providing an anonymous ftp service or sending batched news to the
recipient, or sending mail to the recipients of a mailing list.

Don't we need some sophisticated scheme to stop the sending host cheating
and setting the bit to make the recipient responsible for the packet?
I don't think so. The recipient will see the bit when the packet gets
to him. If the sender is wrongly setting the bit he will complain to
the sender and to the backbone providers. So one bit is all that is needed.

In the 3 level charging scheme described above this would only apply to
priority packets, though flow setup schemes could have some similar
arrangement. The leaky buck algorithm would only apply to outgoing packets
with the bit set to 0. 

Something would also have to be done about incoming packets with the 
charge bit set to 1. The leaky bucket algorithm won't work well here
because it is too late to reduce the priority of the packet which has
almost arrived. The only simple solution is for the leaky bucket to 
actually drop packets and rely on the higher layer protocol to respond
by dropping the data rate. This can be augmented by a new ICMP message
which will be sent to the sender but intercepted by a router near the 
sender which will then apply an appropriate leaky bucket algorithm to 
reduce the rate of that traffic.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
[The following is a clarifying followup message]

>Level 1 & 3 leave me with a cynical suspicion that basic level 1 service
>will be less and less valuable as time goes on.  From a commercial
>standpoint, level 3 is where revenue expansion exists.  

I failed to make an important point. Suppose you want to connect to
the Internet to provide a service to others. Perhaps you want to make
your catalogue available for people on the Internet to browse. You
have no initial intention of using the Internet yourself. Then you
can connect for level 1 service and say (perhaps through some new RRs
in the DNS): "I intend to set the reverse charge bit on all packets
I send - don't connect if you don't like it".

The big win for the Internet here is that service providers get to
connect for the minimum possible cost. They can get a T1 pipe and
not be charged as if they were about to flood the Internet with
real-time video. We've really got to do something like this to make
it as cheap as possible for service providers to get on to the Internet.

Another advantage of the 2 level scheme is that you can have priority
service at a very low rate. For example you might decide that all
the mail you send plus mail you receive from mailing lists can be
handled by 300 bps or less priority service. I don't imagine that
service providers would put leaky bucket filters on all lines: they'd
keep an eye on it through sampling and put the filters on people who
seem to be going beyond what they've purchased.

Note also that there would be no restriction on priority packets unless
they go on backbone lines provided by the service provider. So you can
use priority packets to talk to other sites connected to the same Local
Network Access Point (LNAP). This should meant that you can get your
news feed from a local distribution point without using your priority
packet quota (though the distribution point may require a contribution
to cover their cost in receiving the news).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
[Additional note]

My suggestion above that excess high-priority packets should be reduced
to an intermediate priority is wrong. It would mean that you could
buy a very low speed priority capability and use that for all your
traffic with the effect that you don't have true priority but you
are still doing better than all the no-priority packets.

Priorities need to be matched to policies. I can only think of two
policies:

 1. Drop these packets whenever you feel like it and we won't bother
    about them.

 2. We aim to keep the network configured so that there is no significant
    sustained loss of these packets. 

So there should only be 2 priority levels. Consider the alternative:
we have a medium priority. Network links are not upgraded when medium-
priority packets are dropped, so what are you buying? You're being
invited to give more money to the service provider for no service:
just the right to beat-up other users of low-priority packets. Ethically
dubious.

Bob Smart

Robert.Smart@mel.dit.csiro.au                      Open Systems Program
CSIRO Division of Information Technology           phone: +61 3 282 2625
723 Swanston St, Carlton VIC 3053, Australia       fax:   +61 3 282 2600