Can of worms...


WANCHO@SIMTEL20.ARPA
Mon, 14 Sep 1987 22:58 MDT


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



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