Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!necntc!ames!sdcsvax!ucbvax!SIMTEL20.ARPA!WANCHO From: WANCHO@SIMTEL20.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Can of worms... Message-ID: Date: Tue, 15-Sep-87 00:58:00 EDT Article-I.D.: SIMTEL20.WANCHO.12334716062.BABYL Posted: Tue Sep 15 00:58:00 1987 Date-Received: Wed, 16-Sep-87 06:31:05 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 74 Andy, The main reason for even bringing up AHIP/AHIP-E is because that is the level this host talks to the PSN. As I understand it, the only logical place to account for host traffic is at the PSN level, and the PSN knows nothing about any protocol layers above its own - at least, it's not in that business to know. All that means is that no matter what scheme is developed for accounting of packets, any exceptions must be somehow conveyed to the PSN about each packet. If DDN X.25 already has this capability, fine. However, I doubt you will see those of us who have been running the old 1822 (a.k.a, AHIP) rushing out the door to retrofit an X.25 interface just because it doesn't and won't have this feature. In our case, we will probably just move to the backside of our gateway. Now for your specific comments, objections, and questions: 1. Because it appears that traffic through a PSN cannot be identified on a per-connection basis in order to charge for all traffic in both directions to the originating host, let's define another way: all outgoing traffic is charged to the sending host, except that traffic sent to the originating host is sent collect. It would then be up to the originating host to accept the collect message because it is keeping track of which connections it originated. The host receiving the connection already knows to send all outgoing traffic collect. Same bottom line, but without requiring the PSN to keep track of each connection. 2. How does the TCP driver know to send something collect? If it received the call, then it replies in collect mode. If it originates the call, then the only process that needs to be able to make it collect is SMTP. For large mailing list mail, we already process those messages through its own mailer and it really is trivial to add another option to the mail queue file as it's requeued. A user FTP connection is always charged to the originating host, whether normal or anonymous. 3. When reduced to the final case, all that's left in establishing a collect call is a collect SMTP connection. I would propose that the SMTP server accept the call, but refuse to receive the message based on the addressee, if that addressee is not on a special alias file. The host administrator then has control over which addressees are permitted to receive collect messages. 4. I have no sympathy for the argument that AHIP is fading and thus no changes can be made. If that's the way it is, then other courses of action become economically justifiable. However, conversion to DDN X.25 is not one of them at this time. I am painfully aware that the solutions I have proposed are worse than the problem. But, the currently proposed charging algorithm has many gaping holes in it which allow charges to be incurred which can only be controlled by dropping those services. I don't really want to do that, but I may have no choice. I'd really prefer someone in authority to declare usage-sensitive chargeback self-defeating and drop it. Finally, TAC access under the planned chargeback is simply uneconomical. I can put in more direct lines with no changes required to our accounting log mechanism at a one-time cost of much less than one month's TAC Access charges. I can buy several mainframe class computers for what those charges would be in a year. I'm sorry, but I don't believe in unchallenged pass-through charges to our users, especially when I can offer far superior services on a direct connection at no additional charge. What do I get for $0.075 per minute dialup connect time and anywhere from $0.60 to $4.00 per kilopacket on a TAC? The right to charge back to my host at the highest possible packet rate - one character per packet - at some of the lowest data rates available!!! Maybe if there was some local intelligence capable of handling some of the more popular file transfer protocols at the TAC level which can potentially increase the packet size from 100 to a 1,000-fold (and reduce the charges by the same factors) and access at 2400 and 9600 bps to reduce connect time, I might reconsider. --Frank