Axiowave Queues in the Core

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 7 / 10 > >>

indianajones 12/5/2012 | 1:39:26 AM

re: Axiowave Queues in the Core whyiswhy,

Now, now, why would you go and give me a "one" ? Just for kicks, I went and got me a '5' and now my grade is '3'. Note to LR: Please scrap the point system. It is utterly useless. Fortunately, I don't determine my self-worth from the grade I get on LR message boards :-)

As per your kind referral, I paid a visit to Bandwidth.com and searched for some typical bandwidth prices. Here are some results:

(1) OC-48 circuit between Los Angeles and New York is quoted from $22,000 per month to $96,000 per month. Actually, there are quotes at $150,000 per month, but let us leave them out for now. An average gets you ~$60,000 per month. Or $720,000 per year in recurring costs. This does not include installation costs.

(2) OC-192 circuit between LAX and NYC is quoted from $100,000 per month to $180,000 per month. There are some outliers as well that are offered at $500,000 per month. But let us not include them for the moment. An average yields $140,000 per month, or $1.68 million in annual recurring wavelength charges w/o installation costs.

(3) Let us do one more exercise across the pond. An OC-12 unprotected circuit between NYC and London is quoted between $10,000 per month to $50,000 per month. An average is $30,000 per month or $360,000 per year. You typically have to buy a protected circuit because you are going over the ocean so that puts a protected OC-12 circuit at $720,000 per year.

Well, you get the picture. A point-to-point wavelength circuit which is what carriers w/o optical facilities need to lease on a monthly basis is by NO MEANS CHEAP. So please do not go about parroting that "bandwidth is cheap". Transit prices are definitely coming down and that strongly supports the notion that carriers need to offer premium products and that too quickly if they are to survive.

Re. your "proprietary" comment, it is pretty obvious that routers have proprietary switch fabric architectures. Cisco, Juniper, all of them have developed their own switch fabric architectures. Nothing new there. As long as Axiowave supports standard MPLS signaling and routing protocols, they should be fine.

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/5/2012 | 1:39:26 AM

re: Axiowave Queues in the Core
Well, I'm still not able to get the .ppt, but I'll point out a couple of things... It appears that they were testing with 10GigE and GigE interfaces. One of the problems that we discovered and didn't recognize early on was that disparity between the clock rates of the test equipment and our equipment caused some congestion issues.

Since GigE is not synchronous, and the spec allows considerable tolerance in clock speeds, a tester can conceivably throw traffic at a UUT faster than it can be drained. This causes simple congestion in the router and can therefore demonstrate considerable latency.

My recollection is also that they were testing BE traffic, without a limit on the queue depth. Under these circumstances, latency can easily grow. They were NOT testing QoS, as I recall. For BE traffic, you WANT the queue to build, so this seems like appropriate behavior to me.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

procket_guy 12/5/2012 | 1:39:25 AM

re: Axiowave Queues in the Core carrierguy - let's just drop the facade, I work for Procket, you work for Axiowave.

Using old performance data using pre-production hardware to demonstrate your points against the competition is a weak argument. I would be very careful about saying how this proves anything if you have no better evidence than this. Take it from someone who knows, a centralized shared memory architecture provides very granular QoS capabilities as well as bounded latency and jitter for priority traffic, including multicast traffic.

What I haven't seen is any data supporting your claims as of yet.

Check out http://www.procket.com/pdf/dat...

procket_guy

Reply | Post Message | MESSAGES LIST | START A BOARD

Truelight1 12/5/2012 | 1:39:24 AM

re: Axiowave Queues in the Core Does anyine now when these products and companies reach profitability. They all seem to build the biggets and best core router but they do not hack it on the revenue side.

Reply | Post Message | MESSAGES LIST | START A BOARD

sgan201 12/5/2012 | 1:39:22 AM

re: Axiowave Queues in the Core Hi,
I am not a core router expert. In fact, I am an edge/access network kind of person. So, I am confused about all this discussion about the advance QOS mechanism on the core mechanism. Why do you need it??

The best mechanism for delivery QOS guarantee (in order of capability) are
1) WDM
2) TDM
3) ATM
4) MPLS
5) IP

And, the application that required High QOS, low jitter and delay are
A) VoIP and
B) Business transaction
C) Online gaming

Bandwidth demand for both A ,B, C are very low.

Given this situation, it would seem to me that it is easier and cheaper to multiple parallel IP network at the core. The core trunk will be partition by either WDM or TDM mechanism. The dedicated network for VoIP could have very small amount of bandwidth since it does not required a lot of bandwidth.

If what I said is true, all you need is a simple core IP router that run very fast and use DiffServe to decide which IP network to forward the IP packets at the core. And, supplement with a CAC mechanism, to reject VoIP calls if the demand is too high.

For eample, you could have 3 core IP network:
Gold -> no over-subscription
Silver -> 2 to 1 over-subscription
Bronze -> Best effort
What am I missing here??

Dreamer

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Axiowave Queues in the Core dreamer101 asks why we don't simply run separate priorities on separate core IP networks:
"For eample, you could have 3 core IP network:
Gold -> no over-subscription
Silver -> 2 to 1 over-subscription
Bronze -> Best effort
What am I missing here??"

You are missing the fact that IP has no provision for allocating bandwidth, since it is connectionless. Therefore, there is no way to guarantee that oversubscription will not occur. The concept of "subscription" requires the network to be aware of connections.

So, we are back to addressing the question: Is it cheaper to add a universal connection-oriented prptocol to the Internet and maintain state everywhere, or is it cheaper to overprovision and trust to statistics to see us through?

Dreamer101 did raise an additional relevant point: the percentage of premium traffic is small.

If this remains valid, then the Internet is globally grossly overprovisioned with respect to premium traffic, so if core routers simply operate FIFO by priority, the permium traffic will get premium service in the core. This dramatically reduces the chance that a particular core link will become overloaded, but it does not provide an enforcement mechanism.

Reply | Post Message | MESSAGES LIST | START A BOARD

whyiswhy 12/5/2012 | 1:39:15 AM

re: Axiowave Queues in the Core OK, let's take your premise that one would be so foolish as to take the average price for a link between NY and LA. I mean, most intelligent business people would only talk to the cheapest and drive them even lower, but hell, go for it: $1.68M per year for OC-192.

What do you think the original hardware and rights of way and installation costs were for that link (let's say it is four years old), and what do you think the annual maintenance costs are, today?

Just give me some wild ass guess figures...then let's talk again.

-Why

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 1:39:01 AM

re: Axiowave Queues in the Core arch_1,

MPLS does provide a connection-oriented framework to handle this. You are raising the issue of the cost of adding this connection-oriented framework to IP, which is a very valid point.

I really believe that it can be done if you limit the number of different service classes to something small, say 3 to 4. The number of states that one needs to keep in the core is within limits and we can still achieve a good service model without over-provisioning. I am not arguing for a flow-based core - too much complexity with no real tangible return.

It is not entirely true that premium traffic cannot take up a lot of bandwidth.
Uncompressed HDTV streams consume a lot of bandwidth. A single uncompressed HDTV stream can take up as much as 1Gbps bandwidth - see some papers from USC Information Sciences Institute.
Storage applications like data replication also involve transfer of large amounts of data.

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 1:39:01 AM

re: Axiowave Queues in the Core whyiswhy,

If you look at the cheaper quotes at bandwidth.com, you will notice that it is for a longer contract duration whereas the more expensive quotes are for shorter duration. Probably the right way to do this would be to see what the cost would be for a 3-5 year period. I just wanted to use a first order approximation, so I used an average quote. Mind you, I did not consider a lot of higher priced quotes. But that is besides the point.

If you agree that $1.68 million is not cheap, consider a MSO who would need to buy several such long-haul routes from someone like Level3 or Global Crossing and have this recurring expense. Doesn't it follow that bandwidth is "really" not cheap and carriers would be better served by using this asset wisely and efficiently?

I am not sure why the original rights of way, installation costs etc. four years ago matter? No one is disputing that those costs have come down. What matters is today's cost and it is $1.68 million per year between LAX and NYC today. Chew on that the next time you go shouting "Bandwidth is cheap"

Reply | Post Message | MESSAGES LIST | START A BOARD

Sakarabu 12/5/2012 | 1:39:00 AM

re: Axiowave Queues in the Core why have multiple customers purchased the equipment (hint: not all deals have been announced)

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 7 / 10 > >>