Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!labrea!jade!ucbvax!CC5.BBN.COM!malis From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: Can of worms... Message-ID: <8709141635.AA26572@ucbvax.Berkeley.EDU> Date: Mon, 14-Sep-87 12:41:23 EDT Article-I.D.: ucbvax.8709141635.AA26572 Posted: Mon Sep 14 12:41:23 1987 Date-Received: Tue, 15-Sep-87 06:18:10 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 84 Frank, As a host administrator myself (as well as a PSN code developer), I understand your concern about the costs generated by the usage-sensitive chargeback. However, I can find several problems with your proposed "collect call" connections: 1. Even though AHIP traffic is sent by the network using internal connections, the AHIP host interface is not explicitly connection-based. There are two alternative ways a host could identify "collect calls": a. Add explicit connection-based mechanisms to AHIP. This would effectively turn AHIP into a variant of X.25, and would require a very large implementation effort in the PSNs and in hosts. By the way, this would be required for the network to be able to automatically charge a host for all traffic it generates in BOTH directions of a call it originates, as you suggested. b. Add a bit to the AHIP message leader, specifying collect charging for this message. This would require that for each such message, a receiving host would need some sort of reply mechanism to either "accept" or "reject" such a message. These acceptances or rejections would have to be passed back through the network to the originating host, which would have to send them back up to the IP and TCP layers. This, again, could not be classified as a "trivial" change to either the PSN or host software. And what do you do about hosts that don't upgrade? Are they forced to accept these charges they cannot detect? Or did you have something else in mind? 2. Given a method to identify "collect calls", how does the sending host's AHIP driver know to use it? Does the TCP driver send down, through the IP driver, information that identifies certain packets as "collect"? How does the TCP driver know? For example, how does the mailer daemon distinguish mail that is to be sent collect from mail to be sent normally? How does the user FTP program know, when it establishes the FTP connection with the other host's FTP server, that the user plans to log in to the server using an "anonymous" login? You see possible problems. 3. How does a host receiving "collect" messages know whether to accept them or not? If hosts just blindly accept all collect messages or calls, then I can program my host to ALWAYS send traffic collect. 4. The DDN PMO generally considers AHIP to be fading away as more X.25 hosts join the ARPANET and MILNET. They are also very resistant to any changes to AHIP that require changes in host software, because they have no control over the hosts and their AHIP implementation. For these reasons, there is no assurance that AHIP-E will ever be accepted and implemented (don't start those host implementations yet, folks). In fact, I am currently working on defining an alternative to AHIP-E that will require NO changes in host software. 5. The only PSN work the DDN has currently authorized for this usage-sensitive charging is to add usage data collection and reporting to the AHIP interface code. This function already exists for the X.25 interface. They have not authorized any changes to the actual AHIP interface for this. There are other problems I could probably bring up as well, but you get the point - a technical solution at the PSN level isn't really feasible. If you are concerned about the costs of your host's traffic levels, my advice is to look into methods of controlling the traffic (such as some that you suggested yourself), or seek an administrative solution by bringing up these issues with the DDN PMO before they finalize their charging policies. I am also curious why you would consider discontinuing TAC access for your regular users. Any DDN charges for this access should be directly recoverable from your users. Regards, Andy Malis PSN Development