Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!purdue!decwrl!ucbvax!PANDA.PANDA.COM!MRC
From: MRC@PANDA.PANDA.COM (Mark Crispin)
Newsgroups: comp.protocols.tcp-ip
Subject: Packet accounting
Message-ID: <12392527963.7.MRC@PANDA.PANDA.COM>
Date: 22 Apr 88 17:49:15 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 43


     Walt Haas' idea certainly makes the most amount of sense, provided
that the concept of a "VC" under IP can be clearly identified to the
accounting processes.  It's a bit harder for UDP than TCP, but it still
can be done.  It is important that only packets which are delivered to
the destination are charged.  I won't worry about packets getting dropped
at a site's LAN -- if they have a too-high drop rate then it's their own
responsibility to fix their LAN/gateway!!!

     This seems to be a reasonable model for a typical "service host":
 . Telnet - accept collect calls (since the site is presumably already
	billing the customer and network charges can be easily added to
	the bill ala CompuServe, etc.)
 . FTP - accept collect calls for login FTP.  Create a *new* FTP service
	for non-login (ANONYMOUS) FTP that does not accept collect calls.
 . Mail - do not accept collect calls for ordinary mail.  Create a *new*
	mail service for bulk-distribution (mailing list, newsgroup,
	etc.) mail which does accept collect calls.

     The idea behind such a model is that the service host is charged
for network traffic only when those charges can be clearly passed on to
a customer of that service host.  When an external agent is benefiting
from access to the service host (e.g. ANONYMOUS FTP) that agent foots
the bill.  In mail, I follow the model of postal mail in that the sender
puts the stamp on the mail.  The "bulk-distribution" service is sort of
a misnomer; a better name would be "collect mail".  A site which doesn't
want such mail can simply not offer the service; of course such a site
may miss out on mailing lists, newsgroups, file transfer via mail, etc.
It would be up to the site to decide upon how to handle the charging.
One way would be to have a more limited list of recipients of collect
mail than for ordinary mail.

     The technical problems in all of this are relatively straightforward:
1) the accounting mechanism must be in place and it must be clear to all
   parties who is paying for the datagrams!!  Some mechanism is needed to
   handle those datagrams that don't neatly fit into a "VC" model.
2) FTP and Mail probably need to be split into two additional services.

     I am also assuming that it must be clear to all concerned that
accounting begins and ends at the DDN.  You won't be charged for packets
the DDN drops, but if your gateway drops lots of packets that's tough.

-- Mark --
-------