Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!telebit!brian From: brian@telebit.com (Brian Lloyd) Newsgroups: comp.dcom.lans Subject: Re: WAN Bridge/Router over Fractional T1 (64K) Keywords: PPP bridge Message-ID: <1991Apr17.050353.7654@telebit.com> Date: 17 Apr 91 05:03:53 GMT References: <1991Mar27.152925.8267@exloghou.portal.com> <1936@crackers.clearpoint.com> Sender: news@telebit.com Organization: Telebit Corporation; Sunnyvale, CA, USA Lines: 229 Nntp-Posting-Host: napa.telebit.com In article <1936@crackers.clearpoint.com> martillo@crackers.clearpoint.com (Martillo) writes: >In article , emv@ox.com (Ed Vielmetti) writes: > >After seeing Vielmetti's comment, I reread RFCs 1171 and 1172. This >rereading reinforced my conclusion PPP is rather inelegant I agree, it could be simpler for what it accomplishes >, mostly harmless Again I agree >and not terribly relevant. Here I disagree with you totally. You go on and discuss how many elements of the protocol, such as the attempt to be HDLC compatible, are superfluous. I agree. I also agree that the finite state machine is excessive ornamentation for so simple a protocol. I agree again. From this point I believe that our viewpoints divide. >1) The PPP RFCs suggest no obvious method of billing except perhaps >timed circuit or leased-line billing. While true you seem to forget that much of the Internet makes use of point-to-point links. Billing is not necessarily an issue. Connectivity is. PPP provides a means whereby routers and hosts of dissimilar manufacture may be combined into a network. Until PPP no standardized mechanism existed to do this. >2) The PTTs are ill-disposed to DARPA Internet style computing and all >protocols associated with such networking systems. The PTTs are not building too many networks here in the US. And even if they are "ill-disposed" many people still find them useful and manage to use DARPA Internet style computing and protocols anyway. >3) ISO is committed to a very different architecture of computer >networks than the DARPA Internet uses and association with the DARPA >Internet will prevent any acceptance of such a standard. Prevent acceptance? All of the major router manufacturers support or have announced support for PPP. Quite frankly, there are many people who are more interested in whether something works than in whether it has been blessed by ISO. >Billing is a serious issue because people use packet networks when they >want to be billed on a per-packet basis. But in an internet, who should >be billed? The endpoint or the person who contracts for an intermediate >link. They use packet networks because they want to be billed on a per-packet basis? I prefer to think that they use packet networks because the packet network meets their need as a data transport service. They probably would be just as happy if they were never billed at all :-). >Also IP packets in an internet have no fixed route through a >concatenated network and the medium is unreliable. Concatenated >networks are a big no-no for the PTTs because they allow the possibility >of tail-end hop-off in that packets may hop in and out of public >networks to avoid long distance charges. Such routing is generally >illegal in a large part of the world. Right! You can move your data virtually anywhere. As for legality, there are many parts of the world where it is permitted. >ISO accepts and reflects the needs and preference of the PTTs. I love that one. I may frame it. >In ISO >OSI, the communications subnet contains all the networking logic and >provides end-to-end service to relatively simple end terminals which >take no part in the actual networking logic. The DARPA Internetwork >assumes that the communications subnet might be rather simple (like an >ethernet coaxial cable for example) and that network hosts which could >be relatively powerful computer systems will take part intimately in the >actual logic or routing packets through the network. > >Both models have their domain of application, but even with the frills, >ornamentation and its somewhat antique style, PPP belong more to the >ARPA Internet model than to the ISO OSI model. Who is arguing? >B) Frame Check Sequence > >RFC 1171 p. 7 and p. 8 states the following. > >"The Frame Check Sequence field is normally 16 bits (two octets). By >prior agreement, consenting PPP implementations may use a 32-bit >(four-octet) FCS for improved error detection." > >Actually, if dial-up service is to be permitted, I would argue that in >the interest of convenience for network administrators the type of FCS >should actually be autodetected. In fact, autodetecting the FCS in this >situation is so easy that I have to wonder whether the members of the >IETF who worked on this part of the specification actually had much >experience with implementing this sort of protocol. The RFC's are preliminary. PPP is undergoing evolution. I suspect that what you suggest may actually take place. It has been a topic of discussion amongst PPP developers. >Since PPP is basically a link-level encapsulation with delusions of >grandeur, this protocol is essentially irrelevant for any sort of >sophisticated computer networking via serial links. Please don't tell that to the PPP users who find it quite useful. They may disagree with you. Of course it is a link level encapsulation. That is what it is intended to be. It is also extendable to meet new requirements, such as your suggestion that it somehow provide support for inverse multiplexing. >Generally, transmitting data over serial links requires sophisticated >user-transparent load-sharing over connections, which might be both >packet and circuit connections as well as user-transparent programmed >link and band-width allocation. > >PPP provides no mechanism for such procedures, which is not necessarily >within the purview of PPP anyway. But since the bridge-router boxes at >both ends of the circuits must agree on the implementation of such >procedures, the actual encapsulation specification is basically more >irrelevant to the customer user than the internal bus structure of the >bridge-router box. Sure they must agree. That is what PPP is all about, an encapsulation scheme that ALL the bridge and router manufacturers can agree upon. I would also like to point out that the Telcos in the US will sell you bandwidth in just about any sized chunk you want. You do not really need to combine multiple links of lesser bandwidth to get what you want. >Now it is possible that the IETF expects the bridge-router box at one >end of the link to communicate directly with an end host at the other >end of the link, in which case a bare-minimum lingua franca serial >communications access method has more importance than I would otherwise >ascribe to such a thing, but my market analysis implies that the number >of customers who desire such a configuration is simply too small for >company resources to be devoted to development of a product which >targets this specific need. There are may "leaf" nodes in networks. Please consider point-of-sale applications for example. Other examples might be small satellite computing facilities. Your "market analysis" may imply that this is a small market but ours doesn't. Time will prove one of us right. >Since PPP does not address the question of architecting an IP network >which use multiple serial links, PPP is essentially irrelevant from the >standpoint of a system architect (like me) and from the standpoint of >the customer or network administrator who has an internet which consists >of several networking technologies including serial links. I think that you are definitely missing the boat. When you are archetecting a network and you are using multiple point-to-point links, you can let the IP layer do the work of the network layer. Besides, IP is there to bind your differing networks (even simple point-to-point links) into an internet. >In order to address the question of architecting an IP network which >uses multiple serial links, I have architected into the Little Dipper a >high-performance intranetwork system similar to the Cypress Intranet >Network architecture. Even if both Little Dippers and the boxes of >other vendors both talk PPP, unless the boxes of the other vendors >conform to the Little Dipper intranetwork architecture, the Little >Dipper and these other boxes really will not interwork. Well, if I need to push packets over the Little Dipper network I can implement some interface code that will allow IP datgrams to travel over the Little Dipper network and use it as just one more network in my internetwork. If Little Dipper will accept my IP datagrams and move them on their way toward their destination, great! >The Little Dipper will also support configuring individual serial links >as IP networks as well as half-gateway and half-bridge configuration. >This sort of flexibility, which directly addresses the implementation of >serial IP networks, is probably more desirable than mere PPP (which will >also be present). Basically, if a customer only cares about PPP, and >purchases boxes simply on the basis of conformance to this >specification, this customer will probably have to be content with low >performance serial computer networking. I am quite sure that Little Dipper is very nice. It is also probably proprietary (I appologize if I am incorrect but your posting leads me to belive this). I am not sure that the world really needs more proprietary protocols right now. > >IV) CONCLUSION > > . . . > >The members were afraid that if they produced no documents, >their managements would get upset that the companies had spent >money unnecessarily to send representatives to T1D1. > >People who worked on PPP through the IETF might have a similar interest >in demanding the use of PPP in bridges and routers because otherwise >their managements might wonder why the companies spent money to send >representatives to take part in the IETF deliberations on PPP. > >In the future, I would hope that people who discuss PPP issues would >make clear whether they might be motivated by such an interest. I hate to tell you this but the people who got together to define PPP did not spend tons of money and travel to exotic places to discuss for hours the whichness of the why. They got together to solve a particular problem and discussed it at length via email. Many networking professionals participated on their own time independently of their work. Many of the participants were users rather than vendors. I know most of them and were I they I would be incensed at such an accusation. (Actually I took part in the process myself and I am a little put off by your apparent attitude.) > >Joachim Carlo Santos Martillo Ajami > >The above comments represent my current thoughts as system architect. >They may change as I study issues more deeply and read the comments of >thoughtful critics. The above comments are not product announcements >and are in no way binding on Clearpoint Research Corporation. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333