Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!A.ISI.EDU!PADLIPSKY From: PADLIPSKY@A.ISI.EDU (Michael Padlipsky) Newsgroups: comp.protocols.tcp-ip Subject: Re: Internet Uselessness Message-ID: <8707221453.AA00603@ucbvax.Berkeley.EDU> Date: Wed, 22-Jul-87 10:28:45 EDT Article-I.D.: ucbvax.8707221453.AA00603 Posted: Wed Jul 22 10:28:45 1987 Date-Received: Fri, 24-Jul-87 04:46:43 EDT References: <8707211807.AA09192@mitre.arpa> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 51 H. Craig-- Just to show the unbelievers that there are some windmills even I won't bother to lance, I'll merely answer your final rhetorical question ("The Commercial/PTT networks can do it, why can't we?"): As I understand the "it" John and Andy and I were talking about, it's dealing with presented loads greater than a system was designed to deal with; if you really think the PTTs know how to get five pounds of bits in a two-pound sack, I hope you'll share your knowledge with us all. In other words, if it's physically impossible, even we can't do it--but neither can They.... It would be too Zen to get into the subtleties of the flavor of pie in the sky vs. the taste of bread in the mouth, but I would feel myself remiss if I didn't mention that I've been aware of pricing as a resource-demand regulator since my CTSS days, where Corby told me it was already known for years to the phone company; so I'd suggest that if the PTTs aren't groaning under their presented loads (and for all I know they are but just don't talk about it in public) it's because they have extra-protocol ways of limiting the loads. And, for that matter, if 40-byte headers bother you, how about you be the one who finally does the exercise of totalling up the sizes of the Network (actual), Network ("connectionless" [a/k/a IP], Transport, Session, Presentation, Application, and Management (times 5 or 6) "PDUs": after all, another good way of keeping the loads down is to make things so barococo that nobody can fabricate a load to present, right? pro forma cheers, map P.S. Andy's reply to me, my reply to it, and his reply to my reply should cast some light on the flavor of virtual circuits we were talking about at the subnet processor to subnet processor level; sorry, I don't think you can rightly infer that IMPs/PSNs "are" X.25 node to node. Indeed, the fundamental problem of the Internet in one sense is that there is not and cannot be A node to node protocol at the subnet level, since the subnet level is by definition hetereogenous. Andy is adressing the/a backbone subnet, which contrary to its original design parameters is now dealing with a multiplicity of (to it) ancillary subnets; X.25 on the other limb is offering some (by spec) no more than 56.2 kb/s "trunks", take 'em or leave 'em. It's like comparing apples to orange pits (or pips, if John Laws is still tuned in) to imagine that Arpanet and "the PTTs" are interchangeable. Try hooking say a 10-meg Ethernet up to an X.25 PSN: you've either got a 56.2 bottleneck or you're building some sort of milking machine and paying for multiple X.25 ports even if your Hosts are "doing" X.25 as their end-to-end/"Transport" protocol, but if the Hosts are doing the ISO Stack, you've the same Gateway bashing problems as in the Internet--with, almost certainly, a far less flexible/responsive "backbone".... -------