Re: Can of worms...

Andy Malis (malis@CC5.BBN.COM)
Mon, 14 Sep 87 12:16:41 -0400


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

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.

Andy Malis
PSN Development

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT