Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcnc!gatech!bloom-beacon!think!ames!sdcsvax!ucbvax!A.ISI.EDU!PADLIPSKY From: PADLIPSKY@A.ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707171853.AA26632@ucbvax.Berkeley.EDU> Date: Fri, 17-Jul-87 14:44:03 EDT Article-I.D.: ucbvax.8707171853.AA26632 Posted: Fri Jul 17 14:44:03 1987 Date-Received: Sat, 18-Jul-87 16:45:40 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 48 [The following got to John, but not to the List, thanks to the vagaries of trying to Answer on his foreign To and CC fields:] John-- As I understand your msg, "the PTT way" amounts to Overcharge So That You Can Overengineer. The Internet way, however, doesn't have to be Undercharge And You Must Underengineer. How about, instead, Undercharge And You'd Better Engineer A Lot More Cleverly? For example, I recall that in the Multics NCP [sic] I had a privileged primitive that let me ignore packets from a Host on a blacklist at interrupt time (which was actually used once, during the infamous Network Horror Story Number 5): Why not use a similar trick in Gateways? Say, on a 30-second cycle (or whatever time value seems appropriate) check the per-Host packet counters (added for the purpose) and put any Host that's exceeded a threshold count on the List for the next cycle. A tad arbitrary, perhaps, but much easier to implement than trying to spot and throttle sf-lovers file transfers/SMTPs. (The threshold should probably be a fraction of total packets for the period rather than a set number, so that periods of relative inactivity for other Hosts behind the Gateway can be catered to--but this is just a "frinstance," not a spec, so no matter.) The example isn't necessarily to be taken literally, of course; it's just meant to suggest a principle to the effect that you can combat resource hogging creatively without violating protocol (since Gateways are explicitly allowed to drop packets on the floor) on the one hand yet without having to "go commercial" on the other hand. Actually, I've long suspected that the real problem with the Internet Way is that we draw so heavily on Academe that clever engineering is somehow suspect because it's not Computer Sciencey enough somehow. I mean, granted we couldn't have afforded to throw as much hardware as we might have liked at Gateways from the outset, but it still seems to me that all the pious queuing-theoretic stuff about one buffer is enough and even infinite buffers aren't enough and the like has clouded the issue so much that we still (unless the relevant Task Force is about to step in) haven't come up with a rough and ready congestion control approach because we "know" it wouldn't be "optimal". Well, as I've said before Optimality Differs According To Context. cheers, map P.S. As I recall, the X.25 spec certainly _implies_ that there won't be any dynamic routing, both in one of the error returns and, for that matter, in the whole "virtual circuit" premise (since destination addrs aren't carried in ordinary packets), but, yes, They could do it right despite all that if They had/wanted to. Does anybody know of an implementations that do do it right, though? (And even if there are some, so what? We could have some segments of the Internet which used Multics Gateways if we wanted/had to. Some old saw about weakest links still seems to apply....) -------