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.
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--
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