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) -- Ignore unavailable to you. Want to Upgrade?


To: The Phoenix who wrote (45808)4/30/1998 4:43:00 PM
From: George Coyne  Read Replies (1) | Respond to of 61433
 
<< Well, I'm not at liberty to comment on this. I'd say simply watch this space.... sorry I can't provide anymore detail right now.>>

You're employed by CSCO?

<< ***gary lunges to the baseline and nails a crossing shot down the line***** :)>>

A "crossing shot", or a "down the line" shot? :o)

G. W.



To: The Phoenix who wrote (45808)4/30/1998 5:16:00 PM
From: bucky89  Read Replies (1) | Respond to of 61433
 
Hi Gary,

No..sorry. "Congestion in an ATM network is defined as a state in which the
components of the network, be it the switches, physical links, or hosts, are not able
to meet the negotiated network performance objectives which include (for Qos)
peak-peak CDV - cell delay variation, maxCTD cell transfer delay, and CLR
cell loss ratio. So, when congestion occurs all bets are off and an ATM network
suffers as would an IP network.


I think this is the root disagreement here. The issue is Quality of Service, and what happens when congestion occurs. I say ATM has mechanisms to ensure that the highest priority cells (CBR, VBR-RT) are not impacted when there is congestion. This is true for a standards-compliant switch. Of course, not all ATM switches are made equal, and some vendors' CBR and VBR implementations may be flawed, but the model is for absolute and guaranteed performance for these priority AAL's. Lower priority cells will be impacted by congestion, although to varying extents (ABR, UBR, and VBR-NRT). UBR is connection-less, and functions much like IP.

You are correct about CAC in that a new circuit (VC) will not be added if no
resources exist or if it's addition will affect QoS on other connections, however
CAC is re-negotiated by the end-points periodically throughout the
connection...and you would want this capability since traffic types would vary
thoughout the life of the connection. In IP this is all dynamic...no periodic
renegotiation is required.


I thought you said ATM VC's were static? Now you're saying that it has to be re-negotiated? I think you were right the first time, or maybe I misunderstood something. My understanding is that CAC's do not have to be renegotiated. If the VC is a CBR or VBR-RT connection, then there will be no impact to this virtual circuit in the event of congestion. ATM switches will not let you oversubscribe a physical connection with CBR or VBR-RT VC's. If there is a physical line failure (which is not congestion), PNNI will attempt to reroute the VC through other paths. If it's a UBR or ABR connection and switch congestion occurs, then cells may be dropped according to parameters allowed by that AAL. VBR-NRT requires that average latency requirements be honored.

You discuss this as if RSVP and UNI/PNNI are mutually exclusive...these day's
they are not. Both RSVP and UNI/PNNI (ATM signalling) are used to transport
traffic specifications and QoS parameters into the network. Both employ admission
control before accepting a reservation. But the differences are great. As you
continue to point out IP is connectionless and ATM is connection-oriented. IP is a
robust and dynamic networking architecture where any changes in topology or
resource availability will be addressed by simply rerouting the packets to another
path and reestablishing the reservation state. On the other hand, ATM takes the
approach that reservations are retained for the duration of the connection (even for
SVC's). If, however, the topology changes, then ATM must rebuild the connection
from scratch!


ATM does not need to rebuild connections in the event of congestion, but IP does. A topology change is not the same thing as congestion. IP's advantage is it's dynamic. IP's disadvantage is it's dynamic. See below:

IP uses dynamic routing protocols like OSPF, RIP, etc... Their chief advantage is they are a somewhat scalable way of managing large numbers of very large routing tables, and can dynamically adjust themselves to changes in network usage and topology. On the other hand, this is a disadvantage for QoS. A router path may traverse five routers one second, and then 20 routers the next in the event of congestion. Latency cannot be guaranteed in an environment where the routes are dynamically changing. IP is connectionless, and no one knows at any particular moment how the packets will be routed, nor how many nodes the path will traverse. You cannot guarantee latency (not to mention latency variation) in such a dynamic environment.

ATM uses PNNI which is a static source routing protocol. The initiating switch, if the CAC is successful, knows how many nodes, CTD between nodes, etc... and can determine absolutely what the latency time will be for priority AAL's (CBR, VBR-RT). The path for the VC does not change unless the topology changes. ATM's advantage is that congestion and other changes in network usage will not affect performance of VC's carrying priority traffic.

RSVP could work if it were somehow scalable. Yes, it has CAC, but it only provides relative, not absolute QoS because you never know which nodes it will claim for a particular path. If the network is congested at the particular instant CAC is initiated, then you could end up with a very non-optimal path for the RSVP. But its chief disadvantage is scalability and the additional processing burden it places on routers. Everyone, especially all the ISP's, are complaining that routers are too slow. How much slower will they get when burdened with RSVP?

Mulicast. IP supports bidirectional many to many transmissions. ATM supports
unidirectional point to multipoint. This means that there will be a lot of additional
ATM VC's required to emuliate the IP mulicast model.


I admit this is one weakness of ATM, but there are workarounds.

Heterogeneity. Receivers in the ISA model can requirest and receive different
levels of QoS. ATM VC's are a single QoS. ISA receivers can also renegotiate
QoS levels during a connection. ATM currently requires that a new VC with a
different QoS be established.


What more do you need? Five levels of QoS have been carefully spec'ed out by the standards forum, and they appear to be adequate to cover all possible types of traffic. On the other hand, saddling routers with all these different kinds of QoS leaves them with a single QoS too--very slow QoS.

Result...ATM is very rigid and therefore not as well adaptable to network edges
where flexbility is required. It however is an excellent transport architecture.


I agree here. Routers will not become obsolete by any means. But unless Cisco can think of something quick, routers may become extinct in the core of large networks.

Not true however the CLR (cell loss ratio) can be defined for static network
environments. But as switches or network links fail cells will be lost. This will occur
more in open loop networks or with equipment that has small ingress VC buffers or
with equipment that allocates buffers on a per port rather than a per VC basis. Key
point..... cells can and will be discarded at the network entry point if the portend
congestion by exceeding a negotiated cell rate. It is left to the network endpoint
(read IP devices) to retransmit the packet.


Switch or network link failure is not the same thing as congestion. Of course you'll have packet loss when there's switch failure (just ask AT&T!). But we're talking QoS in the event of congestion, not failure.

Also, I'm not talking about oversubscribing a ATM contract either. You can't stuff 4Mbps down a 1Mbps CBR link. Of course there will be loss of data in this case. I'm assuming that the initiating switch knows how much bandwidth it needs, and properly completes the CAC procedure.

Well, perhaps ASND has a lead right now...and I expect this will be a great year
for good ol' ASND, but I think too many folks on this thread are counting mighty
CSCO out of the backbone race. Too soon? Perhaps.... I expect we'll revisit this
proposition sometime in the not too distant future.


This is interesting coming from a Cisco employee. I too am not counting out Cisco. I like Cisco, and was a shareholder until a few weeks ago when I thought the valuation got out of hand. We buy all our routers from Cisco. But you have to wonder what Cisco's plan is regarding ATM. Are they too dependent and comfortable with their routers? What happened to Stratacom?

Remember once
again, ASND is definitely ahead with there latest ATM products but CSCO has a
great opportunity still to counter. They have lost some contracts, but all is far from
lost my friend. And, if I were ASND I'd be concerned about CSCO coming after
their last business niche after being batted out of the RAS market.


In agreement here once again. My bet is that Cisco will come back with something. But you never know. A LU/ASND competitor would be Chambers' worst nightmare.

bucky89***moves up to the net and nails a stinging backhand across the court***



To: The Phoenix who wrote (45808)4/30/1998 5:19:00 PM
From: Nick Kuritzky  Read Replies (1) | Respond to of 61433
 
Could someone on this thread explain the differences between the ATM switches that ASND, CSCO, FORE, and NN make. It seems that these companies make different classes of ATM switches, not all of which compete with each other. What niche does ASND occupy in the ATM market?