Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!ucla-cs!zen!ucbvax!SIMTEL20.ARPA!WANCHO From: WANCHO@SIMTEL20.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Can of worms... Message-ID: Date: Fri, 11-Sep-87 12:50:00 EDT Article-I.D.: SIMTEL20.WANCHO.12333796945.BABYL Posted: Fri Sep 11 12:50:00 1987 Date-Received: Sat, 12-Sep-87 18:08:43 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 50 The following message opens up an extremely touchy subject on this forum. I am bringing it up here because I am looking for a relatively "easy-to-implement" alternate *technical* solution to the problem which will work in the present TCP/IP environment and in the future ISO environment. The Communications Services Industrial Fund (CSIF) of DCA has been tasked to implement a usage-sensitive chargeback only for hosts connected to the MILNET backbone in the very near future. The problem is that the method chosen is probably the easiest to implement in that only PSN code is involved and no host code changes are required. However, it is the least equitable: simply charge each host for all the traffic it originates and all traffic in both directions from a TAC port. The host is also charged for connect time on dialup TAC ports. No such chargeback is being planned for ARPANET hosts. When this scheme is in place, we will probably have to drop our popular services, such as hosting large mailing lists, ANONYMOUS FTP access to our very large public domain collections, and TAC access by our regular users. With no reason to remain directly connected to the MILNET backbone, we will then move our connection to the other side of our gateway to further reduce costs. Given the cost figures based on our current traffic, (heresy follows:) it might even be more economical to extend our own net using high-speed dialup ala USENET, BITNET, etc... However, it might be possible to create a fair, and therefore, tolerable, chargeback algorithm. It requires a further extension to the AHIP-E protocol and possibly only "trivial" changes to certain host software. To make things equitable, charge the host for all traffic it generates in BOTH directions of a connection it originates. However, (here's the hard part) allow for "collect call" connections to be made and not accumulate charges until the remote host has accepted the call. It seems that part of this mechanism already exists for MILNET TACs in that all traffic is to be charged to each connected host on a connection by connection basis. This alternative would seem to take care of the large mailing list problem in that those messages would be sent collect. ANONYMOUS FTP connections would be charged to the calling host. That leaves TAC access. It would be more economical to open up and add more direct-dial ports to our systems, or put TACs on the other side of gateway hosts, than allow TAC dialup access from a MILNET TAC port. OK, given all that, the only real questions I have for this list are: is it possible to extend the AHIP-E protocol to allow for a collect call to be passed to the remote host, and what would it take to get it implemented and tested in the next year or so? --Frank