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 (45394)	4/27/1998 4:23:00 AM
From: bucky89	Read Replies (1) \| Respond to of 61433

Gary, Thanks for your comments. You're obviously very well-versed in the Cisco way of doing things. I'm not sure why a connection oriented protocol has any advantage over a connectionless protocol when it comes to end to end prioritization. There are two weaknesses I'm thinking of with a connectionless protocol. The first you already guessed--the need for every router to examine each and every packet or flow, which adds up to an awful lot of processing for a large network. This solution does not scale. Cisco's fastest routers are already maxed-out in the core of large networks doing pure switching gruntwork. How can you now expect them to examine states and assign priorities to individual packets and flows? The second weakness is a connectionless protocol cannot do absolute QoS on an end-to-end basis. Latency and performance from source to destination can only be measured and guaranteed in a relative sense. If a network becomes congested, then all traffic will suffer, although to varying degrees. For low priority traffic, performance will be terrible or nonexistent. For high priority traffic, performance will merely be bad. RSVP cannot do something like guarantee 50ms of latency for a particular type or path of traffic regardless of the congestion in the network. ATM can do this very easily. Well, there's a thing called Directory Enabled Networks that places decision intelligence into a set of servers. These servers determine priority on an application (layer 7) basis and also provide security, business management, secure VPN's, and other attributes that ATM can not today. This DEN you're refering to is something new that I haven't heard of. Sounds like an extension of RSVP. Can't competently comment on it, but on the surface it doesn't sound like a scalable technology either. You say it's built on layer 7, but if a network is congested how is the router going to communicate with the server to make the prioritizing decisions? For a large network there will be thousands of new flows appearing in the network every second--does the router have to query the server for every one of these flows? Or if the router caches the decision data, then how much more memory needs to go into the router? Regardless, it sounds like an awful lot of overhead which would make any pre-existing congestion far worse. Again, I don't know much about this--maybe you can enlighten me on it. You ask why I say RSVP will not scale in ISP networks. I say just ask the ISP's. Once again, Cisco needs to listen hard. The ISP's are scoffing at Cisco and all the work they're doing on RSVP. It's not about the space it takes up in the IP header, but the amount of signaling that must take place among the routers and the number of states that must be maintained in a large network. RSVP will cause congestion where there would have been none without it. I know of not one ISP that is using or planning to use RSVP. Every ISP I have talked to looks at this technology with extreme scepticism. Enterprise networks are a different story, and in fact we are planning to turn on RSVP to support voice over IP in some international sites. But this is a very limited implementation involving no more than 20 or so routers. if the precedence information is not in the header than ATM will not be able to prioritize the IP traffic any better than IP. And if the information does exist then IP will do the prioritization and you can run it across you ATM backbone via AAL5 and everyone is happy Not sure if you're familiar with the MPLS strategy, but it is to read the IP header once and only once at the ingress to the ATM cloud, then switch the traffic to the egress of the cloud through use of labels and a pre-existing VC. Within the cloud, ATM will be able to prioritize better than IP because it is a connection-oriented technology, which we discussed earlier. Also, there is a HUGE improvement in latency and packet loss, versus IP routing. The other major problem with this is deployment and management. ATM is management intensive due to its connection oriented requirement...add all the prioritizations and technicians will be configuring the network for years before they can bring it up. Ascend has made excellent progress in a new ATM technology called switched virtual circuits (SVC's). ATM management becomes much easier with this technology and also some pretty good management software is now available. I think you're position is that companies like Cisco will get squeezed out by smart ATM backbones and low margin routers. An interesting point of view. Again it will be interesting to see how this all plays out. I see this as one possible scenario, and Ascend's hope to knock off the king of the networking hill. Whether it really works is a different matter. Lots of intangibles and unforseen tech developments ahead, but at this point it does look like a credible threat, if the only one there is. Packet over Sonet is the competing technology, but for some reason it isn't taking off yet. I recall at least one provider is using it (Sprint?), but how come everyone else is using ATM? Whew, it took me almost an hour to analyze your message and formulate this response. But I must say this has been quite interesting. And I had fun doing it. Thanks again for your message. Bucky89

To: The Phoenix who wrote (45394)	4/27/1998 12:13:00 PM
From: djane	Read Replies (2) \| Respond to of 61433

Hey Gary (OG), do you have any comments on the LU acquisition of YURI? To my understanding, YURI's ATM-edge CPE products don't really compete with ASND's products. Your posts on the YURI thread in early April turned out to be extremely prescient. I sold my very small YURI position today. As I stated last week, I'm looking to add to my long-term ASND position and am hoping (?) for more of a dip. With the DOW down 150, ASND is down about 1 with low/moderate volume. djane