Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Ascend Communications (ASND) -- Ignore unavailable to you. Want to Upgrade?

To: The Phoenix who wrote (28549)	12/22/1997 3:25:00 PM
From: Pullin-GS	Read Replies (1) \| Respond to of 61433

We are in total agreement as far as what ATM has to offer on the LAN. Next discussion.....connection/connectionless. Ok?<G> Regards, Paul

To: The Phoenix who wrote (28549)	12/22/1997 4:21:00 PM
From: Pullin-GS	Read Replies (1) \| Respond to of 61433

Gary, Good information to share. I hope the rest of the thread can bennifit as I have in our exchanges.<G> Oh... I'm sure this was a typo..but for clarification... Not at all....let me explain. ATM is Connection oriented...Not connection-less. Not neccessariliy. Here are the specific levels of service for well know technologies today: ---------------------------------------------- network arch. Service protocols Internet connection-oriented TCP connectionless UDP ---------------------------------------------- OSI connection-oriented TP0, TP1, TP2, TP3, TP4 connectionless CLTP ---------------------------------------------- ATM circuit-like AAL1 connection-oriented AAL3/4, AAL5, assured connectionless AAL3/4, AAL4, unassured For furthur study: gaia.cs.umass.edu IP is connection-less. That is, it does not need a connection (VC) to be pre-determined. Actually I said: >In otherwords unless you are not using a connection-oriented >application (all TCP applications such as TCP, most httml, ftp) >you are SOL. This includes most IP routing updates (UDP and ICMP > based), SNMP, TFTP, some httml. TCP is indeed connection-oriented, in the sense of the true definition: That a connection is established, and a socket bound (as in a telnet connection), where a two-way communication can take place, but in order for it to live each sent packet must be acknowledged by an acknowledgement packet to the sender, thus establishing the reliable connection (or session) that could not be possible with a connection-less UDP session. For furthor reading this is most helpful: foner.www.media.mit.edu You are confusing Virtual Connetions, be it PVC or SVC, with the concept of reliable and unreliable traffice flow, otherwise known as connection-oriented or connectionless session binding. The status of how a connection is made from point A to point B is of no meaning when it comes the reliability of the VC when data is passed. This is defined in QoS, or relative to the applications via connection/connnectionless session definition. These technologies came about because end points had error correction built into them. I understand fully. Please read my explanation of X.25 (connection oriented) and the evolution of Frame Relay (connectionless) in my previous post. So, my response about traffic management didn't specifically address your first issue. But, cell loss usually happens because of bad traffic management (buffers getting filled), not because of packet loss, bad CRC, etc.. This just doesn't happen often enough anymore (in the states) where the overhead is worth worrying about... I agree with your view on the statistics of this happening, but I must say that I am suprised you take the stance of that it does not happen enough to not worry about. The selection of reliable network protocols that can deal with CRC errors (I have seen many a DSU/CSU go bust with only CRC erros as a symtom). I find it my responsibility to take this into account. Comparing the overhead of error correcting each frame versus the overhead of re-sending a lost frame every so often weighed in favor of not error correcting. I agree in most cases that this is true. At least take the load off the network, and distribute it to the hosts, which is what is done when reliable applications are utilized. This decision was made over 10 years ago. Are you suggesting we go back to this technology and error correct and check each packet as it winds its way through the bacbone? No, that is not what I said. It is something that every responsible network archetect must be aware of, and must take into account. For example tell clients to utilize ftp (TCP, connection-oriented, based) vs tftp (UTP, connectionless based) applications. Can you imagine a voice call going through the internet given the response times we all experience? Voice can tollerate some loss. Data can tolerate no loss. This comes back to the question of QoS and how it can be implemented without utilizing QoS/ATM. Regards, Paul

To: The Phoenix who wrote (28549)	12/22/1997 5:37:00 PM
From: Dennis Doubleday	Read Replies (1) \| Respond to of 61433

> If we're talking about making a case for ATM in the LAN, we are in > complete agreement! ATM will never succeed in the LAN. I think this > has been decided already. FORE Systems has a growing list of corporate customers who disagree with you. True, not all are choosing ATM all the way to the desktop, but many are, and those who aren't still view ATM at the core of their corporate backbone as the forward-looking choice that will scale to the multimedia LAN future, while allowing integration of their current LAN via switched Ethernet and Fast Ethernet devices with ATM uplinks.