Will@cup.portal.com (Will E Estes) (02/04/91)
I would like to get opinions on pros and cons for setting up an Internet. The two setups are: 1) All sites on the internet have routers that attach to a public data network, like UUNET's Alternet, and use TCP/IP to communicate between nodes on the net. To the extent that X.25 might be used underneath TCP between the routers, this is invisible to the applications. 2) All sites on the internet connect directly to an X.25 network, and any client-server applications between two sites are written directly to an X.25 API or to some software abstraction that is written on top of X.25. What are the advantages to either approach? Clearly 2) is going to be more efficient since you don't have the extra error-checking of TCP and you don't have the extra data bandwidth of the router headers being attached to each packet. This advantage aside, are there any decisive advantages that argue for approach 1)? Thanks, Will Estes (apple!cup.portal.com!Will)
huston@prime.com (Steve Huston) (02/05/91)
Will@cup.portal.com (Will E Estes) writes: >I would like to get opinions on pros and cons for setting up an >Internet. The two setups are: You didn't say what sort of sites you're connecting, but from your mentioning connecting sites to a PDN, I'm thinking you've got clusters of machines, with the clusters connected by X.25 over PDN...if that's a bad assumption, sorry. >1) All sites on the internet have routers that attach to a public >data network, like UUNET's Alternet, and use TCP/IP to communicate >between nodes on the net. To the extent that X.25 might be used >underneath TCP between the routers, this is invisible to the >applications. >2) All sites on the internet connect directly to an X.25 network, >and any client-server applications between two sites are written >directly to an X.25 API or to some software abstraction that is >written on top of X.25. >What are the advantages to either approach? Clearly 2) is going >to be more efficient since you don't have the extra error-checking >of TCP and you don't have the extra data bandwidth of the router >headers being attached to each packet. This advantage aside, are >there any decisive advantages that argue for approach 1)? Approach 1 (TCP) buys you the flexibility of using a standard API (sockets, streams, etc.) while retaining the flexibility of changing/adding to your underlying network technology as your network grows, changes shape, etc. and communications technology improves. You can mix/match non-X.25 network elements with your existing X.25 parts, and your applications just keep working. Steve Huston +1 508 620 2800 ext 3099 Huston@Relay.Prime.COM Prime Computer, Inc. The opinions expressed above are not necessarily those of Prime Computer.
kwe@bu-it.bu.edu (Kent England) (02/07/91)
In article <38836@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes: > Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip > Subject: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25 > Date: 4 Feb 91 02:09:29 GMT > > I would like to get opinions on pros and cons for setting up an > Internet. The two setups are: > > 1) All sites on the internet have routers that attach to a public > data network and use TCP/IP to communicate between nodes on the net. > > 2) All sites on the internet connect directly to an X.25 network, > and any client-server applications between two sites are written > directly to an X.25 API or to some software abstraction that is > written on top of X.25. > The wording is kind of hard to interpret, since I think "site" is used when "host" might be what is meant, but nonetheless ... I would decouple internet issues from application API issues and loosen up on the "either/or" tone and take an attitude of "one or more". If I had the choice of APIs to write to for client-server applications, it would be a session-style API and/or an RPC API that offers me virtual circuit streams-of-data service, simple unreliable messaging, and a robust transaction protocol that would be able to run on TCP/IP or OSI-IP or 802.2 as part of the operating system I was using. If I didn't have an OS that offered me a good session or RPC API, then I would still write that interface myself and write a lower level interface to TCP/IP and one to X.25. Then if I wanted more transport options in future, I wouldn't have to rewrite my client-server code, only yet another transport option for my session. The idea is to layer intelligently, hide what lower level information can be hidden, but write the API such that it anticipates the wide variety of transport services that it might have to use (connectionless, connection-oriented, high-bandwidth/low-latency, low-bandwidth/hi-latency, ...). As far as internet architectures go, allow for multiple protocols and overlapping transition periods. Keep your LAN and WAN technologies decoupled by using routers or capable bridges. Design with multi-protocol hosts and servers in mind. Give your users options, not mandates. X.25 is a WAN option to use public nets over the use of private lines, nothing more. I don't care for it as an alternative for available LAN technology. It has been more than four years since I heard anyone seriously talk about doing that. :-) --Kent
karl@lvs.Eng.Sun.COM (Karl Auerbach) (02/08/91)
In article <38836@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >I would like to get opinions on pros and cons for setting up an >Internet. The two setups are: > >1) All sites on the internet have routers that attach to a public >data network, like UUNET's Alternet, and use TCP/IP to communicate >between nodes on the net. To the extent that X.25 might be used >underneath TCP between the routers, this is invisible to the >applications. > >2) All sites on the internet connect directly to an X.25 network, >and any client-server applications between two sites are written >directly to an X.25 API or to some software abstraction that is >written on top of X.25. > >What are the advantages to either approach? Clearly 2) is going >to be more efficient since you don't have the extra error-checking >of TCP and you don't have the extra data bandwidth of the router >headers being attached to each packet. This advantage aside, are >there any decisive advantages that argue for approach 1)? Don't bet on approach #2 being automatically more efficient. A router can run a number of parallal X.25 connections and spread the traffic across those. (You may find some X.25 providers will constipate a given X.25 virtual circuit well before you exhaust the interface circuit bandwidth, so by using multiple VCs you can push more packets.) And I doubt that you will reach data rates over the typical X.25 (or TCP or OSI over X.25) that will even begin to make the TCP/IP or OSI checksumming, etc increase to a noticable level. (This is not to say that some networks may offer high performance X.25 service. It's just that most of the providers that I see don't. If they did then your overhead concern would begin to be meaningful. But I suggest that you might find that the burden of dealing with X.25, even at low data rates, greatly exceeds the cost of TCP/IP or OSI connectionless network and transport layer.) Approach #1 will give you more portable code (assuming you are programming to a fairly standard interface like "sockets".) --karl--
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (02/08/91)
Will Estes-- Although I could, if I were willing to risk the Wrath of Postel, offer a semi-reputable definition of "datagram" that would render the notion of "reliable datagram" non-oxymoronic, even I know of no definition of "Internet" that would salvage the notion of an X.25-only Internet. Indeed, by definition an X.25 communications subnetwork is a single net, not an inter-net; that is, "Internet" is not a contraction of "intercomputer network", it's a replacement for the earlier, but apparently too subtle, term, "catenet" (originally meant to convey a concatenation of sundry individual/single comm subnets). On second thought, considering what happened to the term "gateway" once the heffalumpers got at it, perhaps I should say that "Internet" was never INTENDED to be a mere contraction for "intercomputer network", though IFF it were used in that solecistic sense I suppose your second alternative would at least be lexically licit. It would still be a bad idea, however, since it's precisely to allow Host computers attached to various/"all" comm subnet "technologies" to interoperate that the proper sense of Internet (and Catenet before it) was invented for--and it's precisely that breadth of attachment options which X.25 precludes, almost by definition and certainly in practice (since even "X.75"'s presence to connect independent X.25 instances does not cover the very common case of Local Area Networks which are not attached to via X.25, Host-to-LAN; thus, there can't/couldn't be a REAL X.25 Internet until and unless the world went mad enough to force LANs to present almost utterly inappropriate to LAN interfaces). cheers, map P.S. Lest any of the usual X.25 apologists be tempted to argue that X.25 SHOULD be the required interface to all LANs, I'd observe that such matters should only be discussed on the CCITT1996 and/or CCITT2000 mailing lists, not here--and I'd wish them the best of luck in getting it adhered to even if they do get it voted for.... -------
merlin@sulaco.Sigma.COM (David Hayes) (02/08/91)
One question which I have not seen addressed is the cost of the media. X.25 lines are typically charged by the (X.25) packet. Therefore, your monthly cost can vary widely, depending on how much data is sent. All of the present IP network providers sell you a pipe of a given size, say, 56k bits per second, for a flat rate regardless of actual usage. David Hayes