geoff@fernwood.mpk.ca.us (Geoff Goodfellow) (04/19/88)
Packet accounting will make us use "our" networks more efficiently. Packet accounting will derail the virtual gravy train of network pork bellying we've grown accustom on "our" network. Packet accounting will engender new protocols which give us The Look and Feel of today's full duplex, character at-a-time, remote echo telnets & rlogins with local echo transmit-when-needed efficiency. Look how packet accounting networks such as Telenet & Tymnet have developed vs. "our" networks sans accounting. Packet accounting network users usually send terminal traffic line at a time and do local character echoing at the PAD or user telnet level. "Our" networks send telnet/rlogin traffic character at a time and echo at the remote host. No doubt "their" network is making a better use of its bandwidth (although "ours" may currently be `nicer' to use -- but at what cost?). We never really had the incentive to develop austere networking protocols because "our" network was usage and cost sensitive "free". Whether your IMP port sent 1 or a 1,000,000 packets a day, week or year, the cost was the same. Old Time Network Boys will remember the ARPANET's attempt in the early 70's at local echoing of telnet with RCTE via NCP. As i recall from that time, the purpose of RCTE was for the users in Hawaii, London/UK & Oslo/Norway to receive fast/local-like character echoing, not really to cut down on network traffic. I think the TIPs (what today's TACs were previously called), Tenex and MIT-Multics were the only hosts to implement RCTE. RCTE was never fully debugged and used in an operational mode (and i recall Mit-Multics only used RCTE to turn off echoing for passwords at login time). It did not seem to survive the NCP to TCP/IP transition. R.I.P RCTE Network bandwidth conservation is not only A Good Thing for "our" networks, but is an important efficiency in some networking technologies which have very finite amounts of bandwidth available to them such as packet radio, cellular and satellite. With these technologies in the commercial market place, it's not always possible to throw more capacity to gain bandwidth. There is only so much radio spectrum available. We need to be so ever parsimonious with our existing bandwidth/spectrum as possible. Perhaps packet accounting will bring about the networking equivalent of the 70s energy crisis. Fuel efficiency considerations and non OPEC sources of energy suddenly became the seminal issues of the day. Research and development ensued for more efficient motors. Alternate forms for fuel were explored and some developed such as synthetic. May necessity be "our" mother of invention too. __ Geoff Goodfellow fernwood!Geoff@sri-unix.arpa ..!sri-unix!fernwood!Geoff
bzs@BU-CS.BU.EDU (Barry Shein) (04/19/88)
By the same token (pardon me) we could argue to raise the fares on on Rte 128 (for the w. coast, 101) until that messy thing called rush hour just stops. Of course, the sudden absence of employees will be a mere artifact of these nice, manageable highways, it is ignorable. I don't know about software engineering by dear resource, it's not self-evident to me. Computing resources have gotten really cheap lately and I daresay they have engendered better software, not worse. For once in history it is becoming clear who will serve whom (you can't tell me that JCL wasn't an attempt to make man serve the computer rather than the other way around.) Let's be real careful, that's all, I ain't sayin' yes and I ain't sayin' no... -Barry Shein, Boston University
philipp@LARRY.MCRCIM.MCGILL.EDU (Philip Prindeville [CC]) (04/19/88)
4. Charge for higher level services based upon the service (eg. charge for local logins at one rate, remote logins at another rate, based upon connect time, as other services develop their charging units should also develop, distributed data base access based upon queries etc.) As long as we are being open-minded (and perhaps a tad unrealistic), why not charge on the basis of utility derived from a service? I know this is extremely subjective, but I have always been opposed to paying for a service by the service-unit (say packets or message-units) when the actual quality can vary tremendously. Should you pay as much for network usage when the latency and/or lossage is high? Or for SYNs sent to a host that is unreachable because their IMP crashed? If we all had extremely current, well-behaved TCPs then we wouldn't have to worry about paying for packets that are redundant (say the RTT calculation is off and you start retransmitting prematurely). But most of us are constrained to use commercial software that is of varying quality and functionality. I guess I'm moaning about a problem without presenting any sort of solution, but I feel it is something to be considered. As an aside, I would like to see "collect" packets (charged to destination) for mailing lists. There is no reason that the people who provide these enormously useful mailing lists (_not_ soc.singles) and invest time and resources should be further penalized. Maybe FTP clearing houses as well... -Philip
perry@MCL.UNISYS.COM (Dennis Perry) (04/19/88)
Barry, Your comment about the fares on Rte 128 ring too close to home here in No. VA where you cannot ride the 'freeways' during rush hour (on I66) unless you have 4 or more in the car. Recent sentiment expressed in the paper indicates that this will not go away, but willexpand in concept. We are also going to build a private tole road. So, if with hiways, why not networks. Pay and 'packet pool'! dennis
bzs@BU-CS.BU.EDU (Barry Shein) (04/19/88)
>So, if with hiways, why not networks. Pay and 'packet pool'! > >dennis Because we don't have a cartel forcing the price up on bits? (joke) Dennis, it's not a moral imperative or something that one can prove easily is right or wrong. I guess the problem is simply that whatever one does they are forced to engage in a form of social engineering. Unless the charges are so trivial that they can be ignored (in which case they won't have any effect on traffic volume) it will become a decision factor. Some folks have pointed out how this can be a good thing and I was trying to point out that this can also be a bad thing. I guess my views come down to whether we are metering the right thing, not really any PollyAnna view that someone won't pay the bill. For example, why not charge for the length of cable used to hook someone up, by the foot? That's a more direct cost than packet usage, wire costs, bandwidth only costs when you don't have enough (that is, what value is an unused wire?) If charging by the foot doesn't ring true with you then now you have insight into my feelings about metering packets. Places to charge: 1. One-time at point of hookup or, similarly, "rental of equipment" (eg. flat monthly rate.) 2. Per packet 3. Taxation model (thou shalt contribute N% of your overhead to networking.) This is probably the current model even tho it's not obvious to the casual observer (eg what agencies spend on networks they don't spend on other research costs, it's a witholding tax...) I realize that PSN hookups are charged and can more resemble (1), but that's a small part of the picture. 4. Charge for higher level services based upon the service (eg. charge for local logins at one rate, remote logins at another rate, based upon connect time, as other services develop their charging units should also develop, distributed data base access based upon queries etc.) I am sure there are others, I just don't see what's so compelling about packets as the charging unit other than it seems simple and straightforward (as many have pointed out, it really isn't very simple nor straightforward once we consider the details of implementation.) Personally I tend towards the taxation model which could be expanded because it gibes with my view of network as infrastructure rather than utility. Even the traditional public utilities have recognized these sorts of alternate models (eg. 800 numbers) to per-unit charging. -Barry Shein, Boston University
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (04/19/88)
Plug: A proposal for X.3-style line buffering, echo control, output flushing etc. has just been published as RFC 1053. It works pretty well for X.25 networks and can probably do the same on wide-area TCP networks. Stuart Levy, Minnesota Supercomputer Center
BILLW@MATHOM.CISCO.COM (William Westfield) (04/20/88)
And there is also an IDEA016 "Telnet local edit option" from the people at Cray. Just what us vendor type people love. Multiple standards to do the same thing. Well, not quite the same thing. While RFC1053 proposes a PAD view of the world, IDEA016 proposes a unix view of the world (complete with local handling of signals). Personally, I'd like to mix up the two, and add some tops20-like features, like a full break mask, and some things that haven't ever existed, like a full echo mask. Oh well, I guess I just get to wait and see what happens. Bill Westfield cisco Systems -------
perry@MCL.UNISYS.COM (Dennis Perry) (04/20/88)
Barry, I agree with your sentiments. I also tend towards the taxation model and the view of networks as infrastructure or a 'utility'. At Los alamos, where I was before moving east, we charged for network connect time and port charges. Other methods of charging were always discussed, but it was hard to get concensus. The 'rich' users did not care about what you charged. They just justified more money for their work. the 'poor' users could not get more money and were forced into antisocial behavior, i.e. they quit using the network and went out and bought microcomputers. Afterall, you can compute anything on a micro that you can on a cray, it just takes more time. When 'time' is the color of your money, then you spend time instead of dollars. dennis