Cisco, Sycamore Circling Lucent's ATM

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 6 / 7 > >>

sath33sh 12/4/2012 | 9:27:43 PM

re: Cisco, Sycamore Circling Lucent's ATM Shows all the symptoms of a "cell tax" problem. A 40 byte AAL5 datagram is within a ATM cell boundary (40 byte payload + 2 byte AAL5 trailer), whereas 41 byte packet needs 2 cells. Maybe 12416's switch fabric port bandwidth is 10 Gig ATM after all.

> The problem is that the "line-rate throughout
> versus packet size" curve resembles a saw-tooth
> pattern. Throughput does not reach 100% until
> packet size = 70B and it stays at 100% for a
> while and falls to 85% at (88B-90B) and climbs
> in a linear fashion to 100% at ~ 108B or so.

Reply | Post Message | MESSAGES LIST | START A BOARD

beach 12/4/2012 | 9:27:37 PM

re: Cisco, Sycamore Circling Lucent's ATM what method did you use to loop the traffic back

Reply | Post Message | MESSAGES LIST | START A BOARD

hyperunner 12/4/2012 | 9:27:36 PM

re: Cisco, Sycamore Circling Lucent's ATM My 2 cents.

If we start with the premise that MPLS was intended to combine the best parts of IP with the best parts of ATM, and to try at the same time to reduce the problems and issues with each technology it is clearly an outstanding idea. But IMHO it has failed in these goals.

I donGÇÖt think the reasons for failure are technical, theyGÇÖre political. Politics within vendors who are trying to maintain market share dominance (ie. Cisco) or are trying to gain market share (ie. Nortel, Lucent). Additional politics between standards bodies who are so riddled with dogmatic GÇ£business as usualGÇ¥ behaviour they canGÇÖt see a way forward.

There are numerous examples of the first political trend. One poster mentioned CR-LDP as a waste of time. I agree, but only inasmuch as the scalability that CR-LDP offers, especially in edge deployment ought to have been rolled into a combined signalling protocol (in contrast RSVP-TE has some advantages in the core, again IMHO). But Nortel backed CR-LDP and Cisco backed RSVP-TE. Obviously Cisco won, but NortelGÇÖs pig-headed support of CR-LDP led to much wasted effort in the drafts for MPLS, and more importantly Cisco had to actively trash CR-LDP and were not allowed to adopt its good ideas into their RSVP-TE effort (note this is a simplification of what really happened, but hey this is a message board, right?).

Similar political examples exist for VPN architectures at both Layer 2 and Layer 3, and for tons of non-MPLS initiatives in the IETF.

In terms of the standards body politics. Many people today question the ability of the IETF to produce good standards. ItGÇÖs a moot point because the IETF was never set up to produce standards. They write these interesting little ditties called RFCs (in which you canGÇÖt even include a DIAGRAM for goodnessGÇÖ sake). Not my idea of a standard at all. But can they change? Not a hope in hell. Way too much of an GÇ£in crowdGÇ¥ mentality. Even insiders have expressed their exasperation with the way the IETF operates.

Is the ITU any better? Hardly. ItGÇÖs riddled with politics. Look at the way that Nortel managed to drag a few monthsGÇÖ extra life out of CR-LDP by exploiting their dominance of the Study Group. Get rid of the damn thing (CR-LDP) once and for all, and save us all some time and effort!!! On the other hand, at least when the ITU produces a document (and the process is happening much faster these days) itGÇÖs a decent, real, fully documented approach to the protocol or architecture. Compare that to something like the BGP GÇ£specGÇ¥ or the RFC 2547 GÇ£Informational RFCGÇ¥.

Are industry fora such as the MPLS Forum or the OIF the way forward? IMHO no. TheyGÇÖre a symptom of the problem. Just like when your nose fills with mucus when you have a cold. Your body thinks itGÇÖs doing the right thing, but boy it makes a mess!

Is there a solution to this problem? IMHO no. Far too much vested interest to make any significant progress. Does this remind you of the way governments operate? What an enviable example they are to us :-)

hR.

Reply | Post Message | MESSAGES LIST | START A BOARD

sath33sh 12/4/2012 | 9:27:35 PM

re: Cisco, Sycamore Circling Lucent's ATM
Shows all the symptoms of a "cell tax" problem. A 40 byte AAL5 datagram is within a ATM cell boundary (40 byte payload + 2 byte AAL5 trailer), whereas 41 byte packet needs 2 cells. Maybe 12416's switch fabric port bandwidth is 10 Gig ATM after all.

--

Sorry, I meant 40 byte payload + 2 word (8 bytes) AAL5 trailer. Whenever the AAL5 frame just crosses the ATM cell boundary rest of the new cell has to be padded. That explains drop and raise in throughput following a saw-tooth pattern.

Reply | Post Message | MESSAGES LIST | START A BOARD

false_rumors 12/4/2012 | 9:27:33 PM

re: Cisco, Sycamore Circling Lucent's ATM what do they have to lose?
----------------------------
...with what cash??

What do they have to gain?

Reply | Post Message | MESSAGES LIST | START A BOARD

sharuvman 12/4/2012 | 9:27:33 PM

re: Cisco, Sycamore Circling Lucent's ATM For ATM related products, it is time for Lucent and other network majors to shift to Asia as US is saturated and no one dares to invest any more. Asia provides lot of market for networking vendors like Lucent who have a division in India. Since Lucent is having a division of INS in India, they can workout with cheap cost and identify customers for another 5-6 years with ATM core products. It is not the time for cutting jobs. This is the time to sustain for Lucent and if they come out of this couple of quarters with difficulty, they are bound to do well. By laying off it means to loose many good brains.Also it gives negative impression for good engineers who wanted to join fearing job security.(Who wants to risk their future ???) Lucent has to balance out this time, else they might have to face very severe consequences in near future.

Better they expand in Asia with India INS.

Reply | Post Message | MESSAGES LIST | START A BOARD

walter_100 12/4/2012 | 9:27:29 PM

re: Cisco, Sycamore Circling Lucent's ATM Hi hyperunner,
Good post.

On the technical side, can MPLS really provide the fine-grained QoS that ATM provides?
What about the OAM&P features currently available through ATM?

Your input

Reply | Post Message | MESSAGES LIST | START A BOARD

futureisbright 12/4/2012 | 9:27:27 PM

re: Cisco, Sycamore Circling Lucent's ATM Sycamore would get an instant revenue stream which they are not getting right now from their current portfolio.

With revenues down in the basement, reduced staff, and no forecastable recovery, it is reasonable to look for alternatives.

With a $1B war chest, a $600M acquisition could be construed as reasonable.

Plus if it did not work out, Desh and Dan could say that LU messed it up so much it could not be salvaged

Reply | Post Message | MESSAGES LIST | START A BOARD

netskeptic 12/4/2012 | 9:27:23 PM

re: Cisco, Sycamore Circling Lucent's ATM

> If we start with the premise that MPLS was
> intended to combine the best parts of IP with
> the best parts of ATM, and to try at the same
> time to reduce the problems and issues with
> each technology it is clearly an outstanding
> idea. But IMHO it has failed in these goals.

IMHO, the key problem with MPLS is that it is concentrated on fixing things which were not broken.

ATM was supposed to provide a cheap/high- speed/high-density L2 with advanced services, by explicitly exposing internal switch design into protocol. It did not fully delivered mostly due to (1)bad selection of cell size, and (2) selection of one-to-many cell-packet relationship (packet could be split into several cells, but cell could not contain two or more small packets). Small cell size forced headers to be small too, which impaired ability to implement advanced services like ABR/fault tolerance/VPN/etc. One-to-many cell-packet relationship imposed significant cell tax. In addition, small cell size made switch design relatively expensive and imposed heavy toll on advanced service implementations due to high event rate.

MPLS is fixing signalling and alleviated cell tax for long packets. Neither of which constituted a major problem for ATM. At the same time MPLS threw away any hope for ABR services, did not provide header space to implement meaningful advanced services, did nothing to reduce event rate and small packets are still subject to a significant cell tax.

IMHO, MPLS is a costly experiment which may develop into major flop.

Thanks,

Netskeptic

Reply | Post Message | MESSAGES LIST | START A BOARD

fgoldstein 12/4/2012 | 9:27:21 PM

re: Cisco, Sycamore Circling Lucent's ATM >i'd be interested in this board's view on MPLS.

Take Frame Relay and brush liberally with NIH. Sprinkle with gratuitous jargon designed to make the same things sound different.

FR was designed by groups with more of a telco orientation, to be a telco data service. MPLS was designed by IETF to be used by non-telco providers. Both are very similar, sitting just below IP. The MPLS documents even cite ATM and FR as being instantiations of an MPLS frame, as well as its native shim layer.

FR's protocol is rather ugly at the bit layer, but at least it's simple, and actually does the job. And yes, on topic, Cascade did it very well.

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 6 / 7 > >>