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 (28541)	12/22/1997 1:59:00 PM
From: sepku	Read Replies (1) \| Respond to of 61433

Gary, when are you going to email me a copy of that Vertical Systems report for my perusal? Surely you don't expect me to subcribe for one report! As a CSCO long, your data is suspect without due cross-examination. Also, your post to Paul left out one very important detail: you neglected to acknowledge that CSCC is kicking Stratacom's ass. ;o) But then, that's common knowledge. Style Pts.

To: The Phoenix who wrote (28541)	12/22/1997 2:44:00 PM
From: Pullin-GS	Read Replies (2) \| Respond to of 61433

>You make an excellent point here. The problem is however that there is much more besides IP traffic out there. Voice and video are becoming big drivers. Since IP frames can be very large, mixing them with short voice frames or impeding video traffic becomes problmatic. The only way to effectively carry these mixed services today is to create a predictable environement for all traffic - today this is ATM. Or 1) A well designed frame-based network, with priority-based traffic patterning. SONNET comes to mind, alocating specific "channels" for voice and video, and provision other channels for your data traffic. Properly modeled networks can utilize this most cost-effective, performance-oriented transport model to fit any data/RAD application today. After all, many ATM backbones ride on top of SONNET. Why not remove the fat middle-man?<G> OR 2)Traffic shapping by the utilization of logical priority queuing also works well in current routed IP environments if you are dealing with predictable, dedicated bandwidth: not including X.25, 0-CIR Frame Relay, and some poorer ATM/Frame-Relay cariers whose capacities have been reached. Frame (as in non-cell, IP applications) voice and video applications are here today and perform quite well in the above described environment. Even under poorer conditions such as high-latency BECN/FECNing Frame Relay and the ATM counter part these can be controlled to some degree for those applications such as voice/video that are sensitive to it with the use of silicon in select areas (RAM queuing). Some vendors are working to create predictable environments over IP however. Quite a few vendors are. And many strategic aliances have been formed between the Networkers, providers, and these mostly-still-small frame voice/video operations. most vendors will tell you this is years away. All vendors who participate in it that I know of actually have products today. The evolution of these products is stagering, and I have to disagree. Just having products on the market implies that their ideas of it happening in a few years is just not the case. Another good point. The ATM Forum and the ITU could do a lot more to move ATM standards forward. However there exists a stong list to start. Standards for IP over, voice over, and mulitprotocol over ATM all exist. IPoA: (IP over ATM) has many drafts on the table...most of which deal with latency issues of a WAN that is constrained by physics (the famous "C" constant). The most popular way around this is to bump up the TCP window size of the TCP/IP packet. Another draft suggests to decrease the autonogotiation of the window opening-period (make the full tcp window be concieved much more quickly). Both of which change the standard IP packet as it is defined by the IETF. This is no where close to being done, and may never be considered an industry accepted standard. MPOA (Multi-protocol over ATM...to include IP) has a few more installments coming our way, but is by far the farthest major ATM segment to be discussed. One of the standards that must be implemented across the board (ITU-T), and not just by a select few vendors who talk at the ATM-forum meetings is the PNNI standard. At the moment BAY, Cisco, et.all- all do their own thing, and the current PNNI does not fully utilize QoS/hiarchical routing in determining best-path for required QoS SVC provisioning as intended with PNNI1.0. Until this major portion (and I can not stress how major this issue is), ATM will just be another cell-based trasport with little going for it as an incentive for users to jump on. But plenty of reasons not to: 1)Expense 2)Lack of ATM applications (including voice/video/ATM-data-to-desktop) 3)All LANE (Lan emulation) must go through a token0ring/ethernet frame to interface with user hardware/applications. Not to mention LANE has several points of single failure (the LES). Also Where are all the native LAN ATM cards and native ATM client/host OSI-complient stack? 4)NNI (Network-to-Network interface) of the ATM providers are all different (Due to lack of accepatance of NNI standard amongst vendors of ATM hardware....how can a user's single ATM cloud consist of multiple ATM providers? It can't unless the user provision his own ATM DTE as a 3rd entity (data middle man <G>) using heterogenious equipment. Clearly this is unacceptable. 4)At least the UNI (User Network Interface) component is kind of OK. But there are still problems getting BAY to talk to Cisco, etc. Just as there was in the old days (still is) with Gang of Four Frame Relay talking to the ANSI standard. 5)The lack of true ATM expertise to support an ATM network is a huge void. These standards eliminate the liklihood that a cell will be losed thereby eliminating the need to retransmit ("re-send") a frame. This is incorrect. The only way to eliminate the liklihodd is if ATM is connection-oriented (has facilities integrated into it to re-send data that is corrupted). They are reduced, but by no means elimiated. I'm glad you brought this up.... ATM is connectionless: ATM only has a CRC bit in each cell as an acknowledgment that there is a problem with the cell. All traffic following will continue to flow. It is the responsibility of the reciever/sender (the application) to detect this, and re-send the data. 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. An example of a connection-oriented trasport protocol is X.25.....it has to be, because the major application using it (SDLC, the protocol used by IBM mainframes) does not have facilities built into it to request resend of data. Its funny how things evolve. No longer is the burden of connection-oriented (one reason X.25 fell out of favor for fast, sleeker Frame Relay) protocols required. Frame Relay offers something even better....They warn the user of congestion comming towards the users FRAD/Router by sending packets market BECN (Backward congestion Notification), thus allowing the user application to "throttle back" or reduce the amount of data sent until the "cloud" can catch up. Frame Relay also allows the application to send FECN (Forward congestion notification) to the cloud to let it know to slow down traffic sent because it is coming in to fast. Paul, the point of all this is that ATM will be required in the infrastucture to support multiservice (data/voice/video) environments. It's fundamental to the discussion. It's the only fabric known today that can simultaneously support these traffic types by providing distinct QoS. No other fabric can do this today. IP RULE's the enterprise and the network edges...but when it all gets moved across the backbone - ATM will be there. For this reson as the market for IP grows so will ATM in order support the increased user load. Finally, I'll point you to all the major carriers and most ISP's... Their backbones are ATM. Those that are moving back to frame will be missing a huge opportunity for the next 5 years. For the most part I agree. I agree that for the next few years or so ATM will be a tool for the service providers, but the enterprise customer does not have a need. My earlier response to Glenn was more of a comparison of ATM as a USER tool against what frame based LAN technologies offer today. I was comparing frame LAN technologies to those offered by ATM LAN solutions. ATM on the WAN backbone is a given...but as far as the user is concerned, he/she will be interfacing a Frame Relay UNI for the WAN in most cases for data. He/she will be interfacing an ISDN or HDLC nailed-up circuit for voice/video and some data. What happens between DTEs of the user data equipment (routers) is not part of the ANSI frame relay standard, and is not a concern to the user. As far as ATM utilizing distinct QoS for data types, yes, that was the intention. But I have yet to see this in practice. How can it when meat (PNNI) of determining best route in a dynamically changing logical ATM network currently does not exist? Current most ATM solutions incorportate nailed up PVCs that do nothing more that cary data. Be it voice data, network data, video data. It all comes down to one QoS. Not what ATM was intended for initially. It would seem that ATM needs another 10 years to evolve. Regards, Paul