Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!XX.LCS.MIT.EDU!SRA
From: SRA@XX.LCS.MIT.EDU (Rob Austein)
Newsgroups: comp.protocols.tcp-ip
Subject: Whither chargeback policies?
Message-ID: <SRA.12391999638.BABYL@XX.LCS.MIT.EDU>
Date: 20 Apr 88 17:27:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 64

Hang on, this is getting a little too far down in the bits.

Let's ignore the implementation details (counting packets, counting
PSNs, etc) for the moment, and concentrate on what this whole business
is designed to accomplish:

1) Generate some revenue to fund (and expand?) the operational
   network, and
2) Provide some negative feedback (that's a technical term, not a
   normative statement) so that users will make "efficient" use of
   the available network resources.

Let us further assume, that (1) will take care of itself (with the
help of the bean counters who are going to be fixing the rates anyway)
and that our job is to decide what kind of things really need to be
charged back so that (2) will be both fair and effective.

I submit that, at the moment, the two most critical resources on the
Internet are:
a) Long distance trunk bandwidth, in particular (but not limited to)
   the three transcontinental ARPANET trunks, and
b) Gateway CPU time (level-3 routers), in particular (but not limited
   to) the core gateways and ARPANET <=> MILNET "mailbridges".

I would add ARPANET/MILNET PSN overhead, but that's beating a dead
horse, no offense to the martyrs at BBN who keep that code running.

These are also, of course, the two worst-imaginable places to try to
intsert accounting telemetry, precisely because they are so
overloaded.  Nevertheless, if we are going to have to start paying
money per usage for some resource, I for one would prefer to be paying
for these.  Perhaps some of the income can be used to increase the
numbers of trunks and core gateways until they can adaquately handle
the load.

The point someone made a few days ago about examining the incentive
implications of a policy before implementing it is well taken.  For
example, I'd hate to see the above musings turned into a general
charge for router CPU time that encouraged everybody to connect
networks with level-2 bridges.

I applaud the idea of getting a Real Economist to analyze this mess
so that we can giggle at his-or-her ideas rather than each other's.

Lastly, if we're going to use highway analogies, let's not forget US
1A southbound through the Sumner Tunnel to Boston, where the traffic
routinely backs up so badly, in spite of the toll, that it's -faster-
to go 10 miles out of the way on state highways and city streets than
to take the direct route.  Much of the traffic is people who are
either paying by the mile (taxis from Logan Airport) or people who are
using the Tunnel simply because they don't know any other route.  It
happens that just last week I found myself TELNETing from MIT to a
site in CT (to which we have a high speed three-hop link via NSFNet)
via the ARPANET to Pittsburg and whoknowshow from there because the
routing software couldn't tell which route was faster.

I'm not sure how to implement a penalty charge for stupid software,
but it'd probably be a good thing if we could; picture
vendor-of-your-choice being told that ever single customer site would
be hit with a surcharge until they fixed their broken software!
People who think this is a joke should remember Paul Mockapetris's
claim that a bug in bind v4.5 was eating up about a KL-10's worth of
CPU time on the root domain servers last July.

--Rob