Axiowave Queues in the Core

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 3 / 10 > >>

light-headed 12/5/2012 | 1:40:17 AM

re: Axiowave Queues in the Core You gotta love all these Axiowave employees posting... "our box can do what box x cannot... blah, blah, blah"

Guess what Axio-guys? You are already done and you don't even seem to know it. Procket's box has pretty good QoS, programmable ASICs, a nice shared-memory architecture and modular sw. Ask them how they are doing. Rumor is they were acquired for much less than their funding as of last week.

It is very, very cold out there and all the tier 3,4,5,6 ISPs cannot help you now. Another bubble company on the deathwatch...

Reply | Post Message | MESSAGES LIST | START A BOARD

cf4650 12/5/2012 | 1:40:17 AM

re: Axiowave Queues in the Core Listen to what you're saying -- ATM can guarantee a rate but if you overload an IP port, it can't? IP SLA's (e.g. implemented with VPN tunnels, or MPLS LSP's) are assigned MINIMUM bandwidth, latency and jitter guarantees. It's as simple as that, and it does work. The question is what percentage of that big fat OC-x pipe can be sold as premium SLA space. For Cisco and the other vendors, it's 30% or less. Axiowave is saying you can sell 90% of the bandwidth as SLA's. That's the message! No other router vendor has shown they can do it.

Reply | Post Message | MESSAGES LIST | START A BOARD

arch_1 12/5/2012 | 1:40:17 AM

re: Axiowave Queues in the Core There is a fundamental difference between ATM and IP: ATM is connectins oriented, while IP is not. Since ATM is connection oriented, it is possible to know in advance what the maximum committed information rate will be. For premium traffic, this rate can be guaranteed on any port by the simple expedient of refusing to establish too many connections. IF you do establish too many connections (i.e., oversubscribe) then you will have exactly the same problems with ATM that you have with IP.

IP cannot guarantee service, because IP has no way to determine in advance what the service guarantee will be. The only way around this is to make the network connection-aware. This in turn requires co-operation throughout the network. There is no way that Axiowave or Caspian can magically apply connection based techniques within a single router that can fix this: if there is suddenly more high-priority traffic than a port can handle, some high-priority traffic must be delayed or dropped, period.

The practical solution to this is to overprovision the network.

Reply | Post Message | MESSAGES LIST | START A BOARD

light-headed 12/5/2012 | 1:40:16 AM

re: Axiowave Queues in the Core
Maybe the pockets weren't so deep... anyway it looks like they were smarter not to use their own money.

---------------------------
didn't see tenor or equipe's founder digging into their pockets.

---------------------------
yeah, whatever... i am sick of this "funded by the founder" crap... if i made several hundred million in the bubble i would have no problem if i funded my own baby for a few million and it didn't work out. it's not like these guys are laying it all on the line here.

Reply | Post Message | MESSAGES LIST | START A BOARD

go_to_the_light 12/5/2012 | 1:40:16 AM

re: Axiowave Queues in the Core didn't see tenor or equipe's founder digging into their pockets.

---------------------------
yeah, whatever... i am sick of this "funded by the founder" crap... if i made several hundred million in the bubble i would have no problem if i funded my own baby for a few million and it didn't work out. it's not like these guys are laying it all on the line here.

Reply | Post Message | MESSAGES LIST | START A BOARD

arch_1 12/5/2012 | 1:40:15 AM

re: Axiowave Queues in the Core cf4650 says:
"Listen to what you're saying -- ATM can guarantee a rate but if you overload an IP port, it can't? IP SLA's (e.g. implemented with VPN tunnels, or MPLS LSP's) are assigned MINIMUM bandwidth, latency and jitter guarantees. It's as simple as that, and it does work."

Sorry, I don'tunderstand. Are you saying that service providers are currently selling MPLS pipes with SLA to customers, and that these pipes traverse the core? Do these pipes traverse multiple IPSs? How are these pipes provisioned? This is a serious, honest question. I'm not trying to be sarcastic, I'm trying to learn.

Since MPLS is connection oriented, it is possible to provide valid SLA for premium traffic with MPLS, but only if all of the routers along the path of the tunnel play by the rules. Note that this applies to MPLS-RSVP, not LDP, and that it applies to MPLS VPNs, not GRE or any other IP-in-IP.

Reply | Post Message | MESSAGES LIST | START A BOARD

Upside_again 12/5/2012 | 1:40:14 AM

re: Axiowave Queues in the Core Man you know the facts when you say "team is weak" For example, Mr. Sales Baloney, has been baiting and shopping over 20 recuiters up and down the east coast, for more than 3 months, to get a sales person who must know (read be able to strong-arm and swindle) a tier two CEO and make thier stealth product (which they are not aloud to talk about) stick. No wonder the position is still vacant.

Reply | Post Message | MESSAGES LIST | START A BOARD

whyiswhy 12/5/2012 | 1:40:13 AM

re: Axiowave Queues in the Core Couple of points for loyal Axiowave employees to consider:

1) Your totuted "founders" investment was a requirement for outside investment..the opposite of a show of confidence.
2) This means their decisions will not be fiducially neutral, but will favor the preferred investors...i.e. your common options will get screwed, screwed, screwed by the preferred shares when it comes (if ever) to them converting to common in the event of an acquisition.

Last point: I agree with a couple of posters than this is a product in search of a problem. Bandwidth is so cheap these days, touting better utilization of under utitlized fibers at the expense of installing proprietary new hardware at each node along the way somehow seems...pitiful.

Sorry guys, hang on until the job market returns, then run like hell...

-Why

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:40:10 AM

re: Axiowave Queues in the Core I am sure (in fact I know) that one can configure maximum queue depths for Cisco 12xxx and Juniper platforms too. Then why do you get the nasty results you get from those platforms?

Yes, if you use a scheduled crossbar and have HOLB problems, then you will have a hard time justifying a latency bound.

If you do not implement priority queueing, you will have a high, but not unbounded latency latency.

If you have to queue datagrams and reorder them on the other side of a switch fabric that does not support priority, then you might also have a high latency.

There are zillion different ways that you can screw it up, but there are solutions out there for those who have an open mind. For folks stuck religiously to the previous paradigm, well, please study the teachings of the Borg: adapt and survive.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:40:10 AM

re: Axiowave Queues in the Core The practical solution to this is to overprovision the network.

Or to apply some form of admission control. If site A is only allowed to inject X megabits of traffic and it must be destined for site B, and we only care about the case of single failures, then this is a solvable equation.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 3 / 10 > >>