SI
SI
discoversearch

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)
ASND 207.04+0.7%Dec 8 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: bigpicture who wrote (16861)10/13/1997 12:22:00 AM
From: Pullin-GS   of 61433
 
First off, must appologise for taking so long to reply. Now on to business. <G>

1) asnd has some issues, and
Indeed. Several technical ones (which have been gone over time and time again) and more importantly, lack of leadership from management.

2)as evidenced by recent quotes of internet backbone providers...internet traffic is doubling every 3.5 mounths, and uunt specifally said we expect our network to be %1000 larger in three years (John Sidgemore) Issues as I see them:
Issues that silicon and bandwidth can repair, as has happened since the 1st days of Milnet over the past 15 years.

The Max TNT had been running hot, when fully loaded with 56kb cards.
ASND engineers at their worst! Sheesh! Build sub-par quality products, and you get sub-par performance. Perhaps they should have gone with a CMOS logic design, saving the TTL logi technology (read heat) for the power-hungry driver side of the cards...perhaps even substituting MOSFET component for any anolog circuitry involved where possible. But this costs money. Apparently ASND missed on a balance that would satisfy engineering requirements. Bad move. Bad for management letting this happen. These types of problems don't go away with a wave of a magic wand. :-(

[no mention of GRF]: I feal this is because the GRF was a bone throne to them by uunt, (maybe to keap csco on their toes?) and not a contract of signifacance
This could be, but the total router port numbers would pale in comparison to the enterprise RAS port count. Each server would take a maximum of one logical port (perhaps many RAS boxes spread across a switch that terminates into a single router port). The real meat would be represented in the TNT ports.

If you look at Tolly reports
Here it is for those who are curious:
ascend.com

...many on this thread would be interested, but do not know what this document is, or where it can be found. Tolly is an independent consutling-evaluation of technical products that include a vast use of equipment and engineering expertise. They are well respected, and are not biased. I can attest to that. Their work is paid for by the vendors themselves. It is not a service offered by the accademies, such as the Harvard group headed up by Gardner.

You will find that the GRF doesn't move packets like asnd claims...
In worst case senerios (Using the minimum allowable size packets of a given transport or protocol) this is indeed the case. But when using real-world packet sizes the GRF does indeed perform to levels that will saturate most transports available today. The GRF is the hands-down leader on the performance board when comparing it to all existing routers, including CSCO's top of the line model that is shipping now and in the next 2 quarters out. The following is a reply of mine to a CISCO CCIE (employed by Cisco) in response to the Tolly group study. He agreed with my stance as well.
exchange2000.com

The reason ISP's are wiling to put up with asnd's poor scalibility in the ras space, is because no-one NO-ONE is yet to touch them in terms of port density... (In this space REAL-ESTATE is everything!!!
I always thought that Real-Estate was the numeral-uno factor in determing what is scalable and what is not. Please clarify what you mean by lack of scalability.

expect voice over I.P....voice ovver Frame Relay
These aplications are here today. The wide-spread acceptance (and yes, cost of bandwidth) has been a problem in the past.
Also the technology at the transport level of Frame Relay has prevented a voice implementation due to the fact that FR is frame based (variable sized packets), thus creating a variable delay in the delivery of each packet. This causes poor speach quality, requiring queuing on the voice applications running in your FRAD/voice-switch. This corrected the variable delivery of the speech, but caused a consistant delay that can be described as "anoying". As capacities increase, these delays will come down....but. There is the one additional caviat that FR poses: It is a best-effort delivery protocol, meaning if a packet is garbled in transmition, it is not re-assembled using CRC (Unlike X-25) techniques, but is dropped on the floor. It is up to the Voice application to request a resend of the packet. During times of above CIR (congestion) use of Frame Relay, this will happen frequently, with adverse effects on the voice data. With this come the requirement of a priority scheme allowing only your most important data traffic to pass, allowing high priority to your voice traffic. Complicated problems that pose problems to the data-people in that now they're data plays second fiddle. It must be that way with Frame Relay.

...Voice over ATM
This has lots of potencial....if the ATM-Forum boneheads can get around their ego-wars and be done with a set of IMPLEMENTABLE standards of QOS for ATM, and a set of applications/products that scales well into an enterprise data/voice network solution...otherwise there is no hope in hell of getting it off the ground. ATM has CRC cell detection (but uses a connectionless protocol between sessions)

thinking frame relay is dead?...also expect ocxxx from frame relay...
The ANSI and ITU-T Frame Relay standards are not in any way shape or form limited to a capacity of xbps. The standards simply state the set of rules and Frame makup between the customer DTE equipment(router) and the Frame Relay cloud switch port (The UNI...User Network Interface). There is also a definition for a cloud to cloud interface, allowing seperate providers to link up (NNI...Network to Network interface). Also in the standards are the rules required for the interpretation of the signalling (contained on a special PVC..0 and/or 1024). But in no place does it state you can only go Xbps. Also whatever happens in the FR cloud is up to the provider...it can be ATM for all we care. Just as long as the UNI, NNI, and FR Signaling are preserved it will be considered Frame Relay. Now back to your point....yes, Frame Relay will remain here for some time to come. Due to it's light weight, and scalability, expect to see many magnitudes of capacity over what is generally available today (T1/E1). Some providers are offering T3 as I write this.

remember when we were all told analog would max out at 1200 baud?
Boy you are old! <G>

The entire Datacom market is only $30 billion...csco,coms,bay,fore,asnd,shva,gdc,olcmf,mrvc,...etc.
The telecom market is $100 billion...LU, NT,Siemens...etc...
can you say convergance???????????????!!!!!!!!!!!!


I agree 100%. The telecom markets MUST make adjustments...and this includes the long distance providers as well.

Whew!
Done.
Regards, Paul
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext