Axiowave Queues in the Core

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 6 / 10 > >>

opinion 12/5/2012 | 1:39:38 AM

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

Any engineering person who says this should be fired. Obviously he has no financial responsibility or visibility to the operational costs of a network. Maybe with this mindset we should trash all this stat-mux stuff and go back to TDM ?

You are simply wrong. There are ways to make GUARANTEED IP services into a network using IP/MPLS, CAC, policing and shaping. The problem with thinking it can't be done is that too many people relate their experience to legacy boxes that can't make guarantees or provide QOS and than come to a conclusion.

If a router polices, shapes and colors appropriately for a given SLA, enforces reservations made through RSVP to RESERVE a GIVEN bandwidth on a LSP, has appropriate admission controls for that reservation and WORKS and doesn't exceed the RESV (except for BE), it can be done and done easily with little work on behalf of the operator. There are enough TE drafts that couple with the RIGHT HW can make this possible.

I hope everyone sees life after Cisco/JNPR and doesn't take their capabilities as physics! They will SOMEDAY deliver on this and perhaps assist to change your minds and WHEN that day changes, perhaps change the STUBBORN minds of more of you.

The next time you decide to overprovision a network to give you music/movie nad porno seeking PTP friends a break, put on an financial hat and figure out alternatives. Congestion can be a good thing IF you have the right toolkit.

Reply | Post Message | MESSAGES LIST | START A BOARD

opinion 12/5/2012 | 1:39:37 AM

re: Axiowave Queues in the Core RE : " 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."

Uhhh.. Who do you possibly know that doesn't have proprietary HW ?? Get a clue!! Go and install IOS on an M160 ? Install Windows XP on a SPARC.. Should I go on ?

Reply | Post Message | MESSAGES LIST | START A BOARD

opinion 12/5/2012 | 1:39:36 AM

re: Axiowave Queues in the Core "1) Overprovisioning is expensive and other industries (airlines, hotels) do not overprovision.
2) Overprovisioning makes non-premium services so good that customers will not buy premium services. Therefore overprovisioning is bad.

I disagree with both points."

Hey dude, let's see.. A 10G LR interface card costs ballpark street price 100k, roughy an average persons yearly salary. The fiber to connect this from SF to DEN is say only a meager $300,000 a year, 3 times an average geeks yearly salary. You need 2 10G LR cards, 200k and and the 300k/yr fiber. Ok, thats 500k for the first year..

Personally I think every porno starved internet user who also wants to do PTP networking for his free movies and MP3's should have the god given right to have carriers overprovision their networks for the $50/month he pays for his PREMIUM service. God bless the overprovisioning network nerds. Anyone know where I can download the Matrix ? It its too slow I want my ISP to pay another 500k this year to save me $10. I'm glad the dude paying $1,000/month for his PREMIUM VPN is saving me the $20.

Reply | Post Message | MESSAGES LIST | START A BOARD

thinker 12/5/2012 | 1:39:35 AM

re: Axiowave Queues in the Core So, when there is a need for new hardware or software, carrier will choose the "better ROI" box.

================================================
if there is no need for new hardware, nobody buys it regardless of your supposed "better" ROI. They exhaust the old stuff. And while that stuff is getting exhausted, it gets super cheap. 3X ain't good enough. Sorry.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Axiowave Queues in the Core No, it could not be more obvious to all here that you work at Axiowave, or are one of their pitiful VCs. Interesting to see you try to refute the bandwidth is cheap arguement by citing the cost of hardware. Obviously a naive engineer (or VC) who does bot understand the basic business equation: if there is no need for new hardware, nobody buys it regardless of your supposed "better" ROI. They exhaust the old stuff. And while that stuff is getting exhausted, it gets super cheap. 3X ain't good enough. Sorry.

-Why

Reply | Post Message | MESSAGES LIST | START A BOARD

carrierguy 12/5/2012 | 1:39:34 AM

re: Axiowave Queues in the Core Tony,

No, I have not tested the 8812 yet. The only information about the PRO series routers I have is from the tests that Eric Weiss from HCS Lab at Univ. of Florida conducted and which seems to have been posted on the web.

The link is
www.hcs.ufl.edu/~weiss/Shared%...

The results don't look very good. Basically if you look at the latency results on slide 16,

(1) 128B frames for the single chassis test had a maximum latency of over 1.25 ms and the average is also pretty high.
(2) The dual chassis tests are even worse. The average latency for all packet sizes is ~15ms and the maximum latency is consistently over 100ms for all the frame sizes.
(3) The frame loss is as high as 3%.
(4) The v6 latency numbers are also in the 7ms range.

These tests seem to have been done with only 20G of populated line capacity and the PRO/8801 switch capacity is 40G, so only 50% of the switch fabric capacity has been used in the tests. Given that, the results are even worse.

There is a note about how the test was done with pre-production switch card (and some fan-in/fan-out problem) and I don't know what that means. Does it mean that the switch card is buggy?

Hopefully, these are not the numbers Procket is going to market with.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Axiowave Queues in the Core
Well, those slides have been removed, so I can't really comment too much. I do recall that that wasn't the final rev of the switch card and so yes, the current production version probably has some improvements.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

carrierguy 12/5/2012 | 1:39:27 AM

re: Axiowave Queues in the Core Removing those slides is probably a good idea. But a google on "eric weiss procket" still gets you the link.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Axiowave Queues in the Core
Please just email me the .ppt.

Whether or not QoS is being tested is CRUCIAL if your concern is max latency. If you test anything other than high priority traffic and you get any congestion (and yes, they were running at full load -- any pertubation will cause congestion) then the latency will soar.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

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

re: Axiowave Queues in the Core Well, I can still get them. They were testing with GigE and 10GigE interfaces.

What you are saying is not consistent with the results shown on slide 16. There is no issue with 10GigE-> 10GigE. But there are nasty issues when 10GigE-> 10 ports of GigE. Why is the packet loss 3% if queues are allowed to build? And what is interesting is that the maximum latencies are dependent on frame size. Frame sizes > 128B exhibit no such issues.

It does not matter that QoS is not being tested. If the latencies are unbounded for a single class of traffic with loading less than 100%, why does it matter if it is BE or premium? As per your claim, you WANT the queue to build for BE even if BE is at 10% with no other traffic present?

The statement
<start><cut and="" paste="">
Due to preproduction switch card used in testing causing a fan in/fan out problem. Scalability tests did not provide valid results due to the preproduction switch card

<end><cut and="" paste=""> appears frequently in the presentation so my guess is that there was something redically wrong with the "pre-production switch card" for the test configuration is pretty benign.</cut></end></cut></start>

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 6 / 10 > >>