WANCHO@SIMTEL20.ARPA (09/11/87)
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
malis@CC5.BBN.COM (Andy Malis) (09/14/87)
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 Developmentseisner@CC5.BBN.COM (09/14/87)
Frank, Just to add to Andy's message - the X.25 interface already supports the reverse charging facilities you desire, and so will the accounting system we will be putting in, for X.25 connections. So, one way to get what you want is to convert your direct host interface(s) from AHIP to X.25, if that's at all a possibility. Regards, Sharon Eisner PSN Development
malis@CC5.BBN.COM (Andy Malis) (09/14/87)
Frank, What Sharon forgot to mention is that while the X.25 interface does support reverse charging, the protocol layering and charging algorithm issues that I raised still need to be resolved before reverse charging can or should be actively used. At least the PSN implementation that you need is available, now all you need is agreement on how and when to use it ... Regards, Andy
WANCHO@SIMTEL20.ARPA (09/15/87)
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.
--Frankron@topaz.rutgers.EDU (Ron Natalie) (09/15/87)
Of course Frank, the DDN is mandated for use instead of putting these cheaper (and possibly better) leased circuits through. Of course, the same people have been insisting we use FTS rather than the cheaper WATS as well. -Ron