Procket Gets Unstealthy

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 9 / 11 > >>

DocGonzo 12/5/2012 | 12:14:45 AM

re: Procket Gets Unstealthy "Are we forgetting history? Who designed the wonderful Crisco box you tear down? umm.. chief scientist tony li
Who helped design the again wonderful junisphere box you tear down? umm... chief scientist tony li."

Your version of history is a bit off. Tony is a smart and capable guy, but he did not single-handedly design the "Crisco and junisphere boxes". He was not even a "chief scientist" at either of those companies (perhaps a factor why he is no longer there.) Also, there are a number of "boxes" available from both companies; several designed after Tony had already left. No doubt that the Procket systems have much of Tony's design ideas in them, some of which are new to the industry.

Seems to me that a good approach for a start-up is to build on what has worked in the past and innovate in areas that differentiate you from the competition. The key areas of differentiation are ones most important to your targeted customers. "Gee whiz" features don't really contribute to your market share.

Procket has the benefit of Cisco and Juniper history and analyzing what they did right and wrong. They were smart to write their own software as that is a critical facet of the offering. I don't doubt that Procket has the talent to write code that will work, but it will take time to work out the kinks. They need to get out of the labs and deployed in large networks in in as many roles as possible. That is their next hurdle to survival. You can't fix what you don't know is broken and lab testing only takes you so far.

Doc

Reply | Post Message | MESSAGES LIST | START A BOARD

simpleton 12/5/2012 | 12:14:38 AM

re: Procket Gets Unstealthy Can we get to the meat of the matter please? The real issue is switching! I am curious that there is no information other than a small paragraph on the switching architecture. Procket mentions a shared memory architecture:

1. Noting that each LC is 40G slot, that would suggest a LC-Fabric interconnect of about 5*4 = 20 SERDES at 3.125 Gbps each, giving a real bw of 5*2.5 = 12.5 Gbps per 10G (the additional BW would be for Procket packet overhead. If they are using 2.5G SERDES, then the total number of links per slot would be 6*4=24. There is a possibility, that they use SONET-like scranmbling instead of 8B/10B codec. Even in this case, to support continuous low packet size input, they will need 20-24 links.

2. The # of links are very high. So, the receiving device on the fabric end must be devices getting either 40G or 80G, no more. This would suggest that from this device to the shared memory is a pretty large mesh on the memory card. To stay non blocking, that is a 480*1.2= ~580G mesh! The fabric board, assuming it is one board would be almost impossible to build. That would suggest multiple fabric boards. This in turn leads to other issues upstream which may cause the number LC-FC links to increase beyond what we calculated earlier (since this would imply cellification at the line cards).

3. So far, we only discussed traffic going in! How does it come out of the fabric that gaurantees no stall or dead time on the wire?

480G non-blocking switch is no joke. Juniper's T640 *is* blocking, even if they claim it is non-blocking because the cross-bar has 4X overspeed (since all you got to do is send 5 OC192 worth of traffic at the same time to the same queue on the same egress port for long enough time (say 30 uS) - at the very least, this buildup will cause unpredictable and increased latency & jitter or pure simple ingress drops due to blocking); the T640 is relying on statistical multiplexing, just as any existing and practical crossbar switch does.

Some information on the switching fabric might help us understand how real the PRO8812 is.

I cannot believe that the power consumption issue someone brought up has any clues to their product being real or not - those calculations are simple, any decent engineer in that area of work can do back of the envelope analysis and throw out realistic numbers. Even if the 8812 is further away from what Procket claims, they would not be so stupid as to miss that one.

/simple

Reply | Post Message | MESSAGES LIST | START A BOARD

signmeup 12/5/2012 | 12:14:38 AM

re: Procket Gets Unstealthy The assumption here is that the software is "brand-new". I know for a fact from friends that the software has been in several large service providers networks for at least 1 1/2 to 2 years. I believe I even remember reading an article about it back then as well, but I can't be sure...

I agree that strenuous real-world testing is crucial, but if the software has actually been cooking for 2 years I would expect that it would be pretty solid - anyone one who has worked with it care to speak up? <g>

signmeup</g>

Reply | Post Message | MESSAGES LIST | START A BOARD

chimpz 12/5/2012 | 12:14:35 AM

re: Procket Gets Unstealthy >
> The people who really understood scaling and
> robustness in routing, they are at
> Procket, Redback and Juniper.
>

I have heard a comment from a "routing guru" that
there are only three companies in the whole
wide world that can really do routing. They
are: Cisco, Juniper, and Redback!

As far as I can tell, the guru didn't think much
of Procket or any other companies.

Screw 3rd party testings, my guru is always right!

Umm, come to think of it, you sound a lot like
my beloved guru! Hi guru!

Reply | Post Message | MESSAGES LIST | START A BOARD

tmc1 12/5/2012 | 12:14:33 AM

re: Procket Gets Unstealthy i am no expert on switch fabrics but i would say your understanding of switch fabrics is very wrong. i really doubt that juniper has a 4x speedup on the t-640 xbar. most speedup is in the 1.2x - 2x range as it is difficult, expensive and usually unnecessary to do more. read anything by nick mckeown from stanford to understand.

secondly, oversubscribing an egress has NOTHING to do with non-blocking behaviour. non-blocking simply means that traffic sent across the fabric in a full mesh will pass at wire-rate without drops. every box ever created is blocking when you oversubscribe the egress. you just cannot get 11 Gig or more out a 10 gig interface... DUH!

------------------------------------------------
3. So far, we only discussed traffic going in! How does it come out of the fabric that gaurantees no stall or dead time on the wire?

480G non-blocking switch is no joke. Juniper's T640 *is* blocking, even if they claim it is non-blocking because the cross-bar has 4X overspeed (since all you got to do is send 5 OC192 worth of traffic at the same time to the same queue on the same egress port for long enough time (say 30 uS) - at the very least, this buildup will cause unpredictable and increased latency & jitter or pure simple ingress drops due to blocking); the T640 is relying on statistical multiplexing, just as any existing and practical crossbar switch does.

Reply | Post Message | MESSAGES LIST | START A BOARD

opticalwatcher 12/5/2012 | 12:14:32 AM

re: Procket Gets Unstealthy Looks like the OS is not completely from scratch. They appear to by using LynxOS, a Linux like embedded operating system.

Go to:http://www.linuxworks.com/supp...
and keep entering refresh until you get this quote:
"Our support representative is fast, responsive and accurate. I hope you keep on improving the quality of tech support."
- Yuet-Fung Siu, Procket Networks

Reply | Post Message | MESSAGES LIST | START A BOARD

indianajones 12/5/2012 | 12:14:26 AM

re: Procket Gets Unstealthy Please re-read Nick McKeown's papers. He concludes that while centralized scheduling algorithms exist that come close to ideal output queued behavior with 2x overspeed, implementing them in practice is close to impossible, especially for more realistic traffic scenarios.

He has written a paper in SIGCOMM2002, August which further re-emphasizes this point. In fact, in that paper he has come out and said that Virtual Output Queued architectures (even with switch speedup) cannot offer any predictability and no delay, bandwidth or loss guarantees can be made. I can send you a pointer to the link if you so wish.

Reply | Post Message | MESSAGES LIST | START A BOARD

rtg_dude 12/5/2012 | 12:14:17 AM

re: Procket Gets Unstealthy tera-
Looks like the OS is not completely from scratch. They appear to by using LynxOS, a Linux like embedded operating system.
As long as they are just using this for process scheduling, mem management, file system access and basic IPC, I don't see an issue. I.e., you still need a kernel to create an environment for your SW, and there is no reason to write it on your own (though some modifications would probably be needed anyways). What they should have avoided is using whatever TCP/IP-related stuff was in it - this should have been taken out to the application level and tweaked to scale. The reason for this is you don't want your kernel's behavior to change depending on what's going outside the box.

rtg_dude

Reply | Post Message | MESSAGES LIST | START A BOARD

andropat 12/5/2012 | 12:14:15 AM

re: Procket Gets Unstealthy DocGonzo,

Couldn't have said it any better.. and I did not mean tony built the crisco and junisphere systems. I just thought and heard he had insight and he is always given too much credit for their designs.

Reply | Post Message | MESSAGES LIST | START A BOARD

andropat 12/5/2012 | 12:14:15 AM

re: Procket Gets Unstealthy Last I checked neither procket nor redback own the core of those guys who actually do have 1000+ routers per AS... and believe me it took Juniper a couple years with one of the best routing teams to get it right. All that happened using BSD which simply needed to be modified..not that I am trying to downplay that. Procket is doing it "from scratch"...

and another thing.. embedded software in my opinion is much harder than a routing protocol.

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 9 / 11 > >>