efbatey%tervax.DECnet@NSWSES.ARPA ("TERVAX::EFBATEY") (04/18/88)
I salute BARRY S.'s thought that it might be a little more complex to account the use by packets, by sites, by ... . Moreover, the internet, a-political as it is, is a place where intellectual processes are nurtured. Some of those might not be nurtured should a carelessly adopted plan evolve to choke off contributions of those automatically excluded by some carelessly adopted plan. ------
engle@wdl1.UUCP (David Engle) (04/20/88)
>... . Moreover, the internet, a-political as >it is, is a place where intellectual processes are nurtured. Some of those >might not be nurtured should a carelessly adopted plan evolve to choke off >contributions of those automatically excluded by some carelessly adopted plan. A good example of what could be easily eliminated by a per packet billing system is the archival storage facilities around the net. How many sites are going to maintain files for anonymous ftp or gratuitous mailing to others, if it costs the site "real" money to do so. Dave engle@ford-wdl1.arpa
wbe@bbn.com (Winston B Edmond) (04/21/88)
David Engle writes: >A good example of what could be easily eliminated by a per packet billing >system is the archival storage facilities around the net. How many sites >are going to maintain files for anonymous ftp or gratuitous mailing to >others, if it costs the site "real" money to do so. This particular problem could be solved with "reverse billing": Create a means for a server and a client to negotiate billing charges. In the case of file archive servers, the server would ask the network to reverse the billing charges. The network then asks the client if it is willing to accept the charges for the file transfer. The client accepts by informing the network that it will accept charges for packets from the server, and the network informs the server that billing costs for that connection have been accepted by the client. It is important that the billing entity (the network) mediate this interaction so that hosts cannot unilaterally shift charges to other hosts. The main problem with this method is that it depends on having an identifiable "connection" that is recognizable by the network billing routines. -WBE
haas@utah-gr.UUCP (Walt Haas) (04/22/88)
It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, all packets on a virtual circuit are charged to whoever established that VC unless the call was placed and accepted as "collect", in which case the recipient pays for it. So if I had a public-domain database of general interest, I could make it available to anyone for anonymous FTP without concern that there would be a sudden explosion of my network packet charges - because whoever called in to copy my data would end up paying for the haulage. To be perfectly honest, I can't see any reason to reinvent a wheel that currently works just fine. Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas
STJOHNS@SRI-NIC.ARPA (04/22/88)
Date: 21 Apr 88 17:14:25 GMT
From: haas@gr.utah.edu (Walt Haas)
To: tcp-ip@sri-nic.arpa
Subject: Re: Packet accounting and a place to do it
It seems to me that the most sensible way to do packet accounting is
the way that the public networks (Telenet, Tymnet) do it - that is,
all packets on a virtual circuit are charged to whoever established
that VC unless the call was placed and accepted as "collect", in which
case the recipient pays for it. ....
Cheers -- Walt Haas haas@cs.utah.edu utah-cs!haas
--------------------
One small problem with this approach - during the life of a TCP
connection, many X.25 connections may come and go. The X.25
connections may be closed down due to idleness or resource
reallocation, and may be reopened from either end of the pipe. Also,
an X.25 connection may carry data from more than one TCP session. And
it may also have UDP traffic mixed in. Who gets the bill?
Mikephilipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) (04/24/88)
Date: 21 Apr 88 17:14:25 GMT From: haas@gr.utah.edu (Walt Haas) Subject: Re: Packet accounting and a place to do it To: tcp-ip@sri-nic.arpa It seems to me that the most sensible way to do packet accounting is the way that the public networks (Telenet, Tymnet) do it - that is, [ ... ] To be perfectly honest, I can't see any reason to reinvent a wheel that currently works just fine. Not everyone is thrilled with the fairness of billing under Telenet. It doesn't reflect the (sometimes) wild variations in quality of service. The longer it takes my packet to get to its destination, the less I'm willing to pay... Anyway, why accept that existing models are sufficient and therefore refuse any possibility of inventing a superior method? The wheel is fine, but there are someplaces it just can't go. So we need the hovercraft too. The MILnet is not a public utility, and should not be run as one. A research facility model is more appropriate. -Philip