Okay, I have a confession to make.
I’ve been somewhat amused by Brocade’s recent “Gen 5” Fibre Channel campaign. After all, the idea that “we’re going to simply call 16G Fibre Channel something other than 16G Fibre Channel and pretend that people will not figure out that it’s really just 16G Fibre Channel” is, well, amusing!
You must give credit where it’s due: it’s brilliant! How else can you convince an entire market to ignore the very obvious comparison between 16GFC and 40GE? For that matter, how do you deal with the fact that not only are there (currently, as of this writing) no major storage manufacturers with 16G FC arrays, but that even when you get them you’ve only got about 33% more bandwidth on the network than 10G FCoE?
Marketing Versus a Standard
I started to realize that maybe my amusement was going to be short-lived when I read an article from Chris Mellor in The Register about “Brocade’s Fat Pipes.” It’s not surprising that Brocade would be pushing Fibre Channel more than Fibre Channel over Ethernet, as reported in the story. (Yeah, like that’s a surprise!) After all, Brocade has less than 1% of the FCoE switching market, according to current analyst reports. Why would they bother to promote something that isn’t their strong suit? That’s like asking Microsoft to comment on Apple’s iPhone in 2007. What do you think they’re going to say?
Even so, it was this paragraph with which I had major issues:
Faster Fibre Channel is coming with a 32Gbit/s standard being developed, the Gen 6 standard. The International Committee for Information Technology Standards (INCITS) T11 Technical Committee is working to finalise the standards for this by the end of 2013. Brocade claims technical leadership of this committee and says it has already initiated research and development for 32gig Fibre Channel technology. Vulture Central suggests we might see initial product appear in mid to late 2014.
This is a huge problem, because there is no such thing as a Gen 6 standard. To conflate Brocade’s marketing campaign with a standard is an outright falsehood. While it is true that Brocade holds the chair of the INCITS T11 Technical Committee, Mellor’s reporting implies that Gen “6” is being promoted within the standards body. However, this simply isn’t true.
In fact, it runs contrary to the INCITS antitrust guidelines:
Sensitive Topics
With rare exceptions that should be made only upon the advice of INCITS counsel, there should never be discussion of the following topics at any INCITS or an INCITS subgroup meeting:
- Any company’s prices or pricing policies;
- Specific R&D, sales and marketing plans; [emphasis added]
- Any company’s confidential product, product development or production strategies;
- Whether certain suppliers or customers will be served;
- Prices paid to input sources; or
- Complaints about individual firms or other actions that might tend to hinder a competitor in any market.
From a marketing perspective, Brocade is free to say whatever it wants, of course. If they wish to bend reality a bit, it’s their prerogative. The argument is made that this focuses on value rather than speeds, but it’s not really clear how: the naming criteria for these generations is based on the speeds, which can handle all of the various features as described in different standard documents.
Brocade makes the claim that customers are looking for a more holistic solution (a view of which I’ve long been a proponent!), but when you narrow the topic of conversation down to a single storage protocol it seems far more straightforward.
I disagree that speed isn’t top of mind when comparing 8GFC to 16GFC to 32GFC because the feature set is exactly the same from one speed to another. That is, when we change the physical layer of Fibre Channel the upper layers of the protocol don’t necessarily change. In fact, it’s because Fibre Channel uses a layering system (similar to the OSI model, for instance), that we can modify the speed of a link without affecting other features of Fibre Channel.
Look at it this way: the T11 Technical Committee of INCITS is broken down into different working groups:
- T11.2 Physical Variants
- T11.3 Interconnection Schemes
Inside these different working groups there are several different committees, each working on various projects. Some have to do with management, some have to do with physical speeds, some have to do with switching, some have to do with security, etc. But apparently Brocade wants to cherry-pick what it wants to include and what it doesn’t:
-
A little from here, a little from there…
What’s more, Brocade claims that their new “Generation” of Fibre Channel switches (which makes far more sense if you’re talking about a product line than a protocol) includes proprietary features that are not part of the standard. To that end, if Brocade wants the “ecosystem to follow,” they may have shot themselves in the foot.
Fibre Channel Standards and the Gen n Problem
Because there are proprietary features in Brocade’s “Gen 5” campaign, the fact that The Register is promoting this as a standard and that Brocade is driving it as such, is problematic at best.
One of the things about standards is that they provide a means to determine what can be done and how a standards-based solution can be implemented. Because of this, the standards themselves allow for testing criteria to measure against. That is, it is possible for a third party testing group to read the standard doc, understand how something works, and then independently measure whether or not a vendor’s claim of compliance is truthful (or not).
As we can see, though, Brocade’s usage of “Gen 5” and “Gen 6,” while excellent marketing, is too arbitrary to measure any realistic qualification or testing criteria. How do you know that something is Gen 5? Who makes that determination? Brocade? Well, we’ve seen how well that matches up with the actual standards, haven’t we?
Imagine that you built trains for a living, and different railroad lines had different width tracks (this happened, by the way, in the US in the 1800s). You would much rather prefer to build the widths of your trains to a standard size so that you could run on any track, right? Imagine a company that says they’ve standardized on the “next generation of tracks” but didn’t actually follow an agreed standard? Hilarity ensues.
If a vendor wishes to claim that they adhere to a standard, they must identify where deviations occur, if such deviations exist. For instance, on Brocade’s FCoE VCS switches they support the FC-BB-5 standard except when dealing with ISLs. In their VCS FCoE data sheets, for example, they call this out specifically as requiring Brocade’s FCS technology as opposed to FC-BB-5’s VE_Port technology.
And of course, there’s nothing wrong with that from a standards point of view. They claim “FC-BB5 [sic] compliant Fibre Channel Forwarder (FCF)” which we can assume (rightfully so, I think) that the FCF handles fabric and FLOGI duties according to the spec. Works for me.
What does this mean in the ‘real world,’ though? Take a look at it from a potential customer’s perspective:
Suppose I’m a government vendor and need to determine if bidders on networks can interoperate because it’s part of my charter, and I want to avoid vendor lock-in. How does this solution accomplish this? Generally I look to standards-compliance as my criteria, because there are good quantifiable tests that the standards provide for ensuring that vendors actually do what they say they do.
At the same token, how do they permit new vendors to bid on contracts that wish to upgrade/expand existing networks? What happens if a company goes out of business? How can a customer move to a new vendor (i.e., “product portability”)?
In short, what good is a standard that isn’t, well, standard?
Why Create Confusion?
Well, look at how difficult Brocade’s job has got to be.
I mean, I’ve talked about this before, comparing the throughput of FCoE as we get into higher bandwidth speeds, and it’s hard not to sit up and take notice that there are reasonable comparisons to be made – especially when you take into consideration that most storage networking environments do not saturate classical 8G Fibre Channel lanes.
I know I put a graph up before about this, but look at the throughput differences between various storage protocols that are available right now. When you take into consideration the encoding elements of the technologies, the actual bandwidth picture looks a bit different:
Okay, so that’s what’s available now. But 32G Fibre Channel is around the corner, right? It’s going to give 40GbE a run for its money, right? right?
Umm…
Uh oh.
I see the problem here. After all, it’s an issue that Cisco has been mulling over as well: Would people really want to move to 32G when it’s likely that 100G FCoE will be available at roughly the same time, and 40G FCoE is available now? What possible use would people have for a dedicated 32G link for FC over a higher-bandwidth 40G link that can be used for any storage traffic?
It’s a conundrum, to say the least. After all, the actual Fibre Channel stack isn’t changing as the speeds increase. That is to say, there’s nothing “special” with Fibre Channel as a protocol that adds anything of value when you move from one speed to the next.
In my head it’s a conversation with the overachieving teacher’s pet:
“I know! Pick me! Pick me! You gotta give 16G another name!”
“But wait, I wonder. Does it include all of Fibre Channel?”
“Naaaaah, of course not. Only what we want it to include!”
“But it’s only going to be stuff that’s actually part of the standard, right?”
“Why on earth would we want to do that? Throw in the kitchen sink, damn the torpedos!”
“Aren’t people going to see through this?
“Hmmm, good point. I know, we’ll convince people that it’s such a great idea that it’s going to be standardized!”
Oops. Hold on a minute there, Sparkles. You’ve just gone a wee bit too far.
General Thoughts
As I mention above, you gotta give props to the “Gen 5” campaign. Personally, I see it as a somewhat dicey proposition considering the question of compatibility (“Will Gen 5 work with Gen 4? Can I mix-and-match Gen 6 switches with Gen 3 storage arrays and Gen 4 optics in my servers? Is there an interoperability matrix I can look at? Wait, I need another interoperability matrix? How do I know what’s supported?”).
Brocade says that their customers love the name change. If they do, they do; personally I tend to gravitate towards “more simple” rather than “more complex” as a general rule. That is, if I move from 8G to 16G, I know my throughput has changed, but that doesn’t mean my fabric, my zoning my logins, or my designs have to change. With the new “Generation” moniker, how can I be sure?
I can’t help but wonder how many conversations go something like this:
“Tell me about 16G Fibre Channel.”
“Instead of that, let’s talk about Gen 5!”
“What’s Gen 5”
“16G Fibre Channel!”
“Um, okaaay…”
🙂
At the end of the day, of course, Brocade’s done a fantastic job convincing people that the 16G FC electronics are the same thing as 16G Fibre Channel. Hell, they got Chris Mellor to advertise their entire marketing campaign for them. Pretty impressive, considering that they don’t have 16G Fibre Channel actually running end-to-end, but they’re already talking about 32G!
Slow clap.
No, I’m not being sarcastic. I’m serious. This is impressive stuff here. It’s one of those things that you see and think, “Daaaayum.” If I had said to myself that I was going to be able to go out and sell an entire technology that wouldn’t be able to be used as designed for over two years, I would have to wonder who spiked my drink. And yet, this is precisely what Brocade has done. Kudos.
At the same time, it’s always been known that the runway was coming up short. Looking at the amount of bandwidth Ethernet is going to provide – and be used for more than just one type of traffic – it’s a fight to stay pertinent.
Let’s not start confusing the issue with standards, however. There is no “Gen 5” Fibre Channel standard, and there is no “Gen 6” Fibre Channel standard. Yes, advances are being made to specific parts of the standard, some have to do with speed, some do not. Some have to do with FCoE, some do not. What you can not do is cherry pick what is convenient to your marketing goal and confuse people into thinking that this is a standard.
Sorry, it just doesn’t work that way.
Very good article and rebuttal of Brocade’s position.
Well said
Marketing in overdrive I think. A very good read
Hi J, great post.
I agree that from a standards point of view there is no such thing as Gen 5 and I think Brocade should update their Gen 5 technical brief from:
“Developed by the T11 technical committee that defines Fibre Channel interfaces, Gen 5…”
to:
“Based on technology developed by the T11 technical committee that defines Fibre Channel interfaces, Gen 5…”
If they had just included those three words, all of this drama could have been avoided. Then again, perhaps they wanted the attention?
BTW, I understand what Scott is saying in his “what-s-in-a-name-brocade-gen-5-fibre-channel-changes-the-game” post, and I agree that people don’t feel compelled to make the jump to the next speed. That having been said, I don’t think making FC harder to understand is the solution to this problem..
Full disclosure, ex-Emulex employee here, just wanted to put my observations on this.
Throughput is only one aspect of performance in storage networks, honestly I’m more concerned with latency and IOPS with specific common workloads than I am on pure throughput. Bandwidth won’t address congestion. My common workloads don’t need the bandwidth, they need the ability to work in parallel with other workloads and not get trounced upon in the process. They also need to be simple and easy to deploy. Additionally, if we are discussing merits of one technology over the other then the cost should also be part of the analysis as well, perhaps on a per port to deploy basis. Yet I digress.
I think the major change in the jump between 8 and 16GFC that most people are simply not aware of is that encoding scheme used has changed resulting in a significant reduction in overhead. Moving from 8/10b to 64/66b was substantial in allowing significant gains in IOPS, to the point where most 16GFC can perform upwards of 1.2 million per port. 10GbE also uses 64/66b encoding but you won’t get the same level of capability that FC can deliver.
You will get no argument from me about the marketecture aspects of Brocades announcement.
As for 16GFC end to end, you can do it today. Dell Compellent offers it, EMC will be offering it in the next few months. HP will follow. The tier 2 array groups already have it (Pure Storage and XIO), lets be honest here its not like 10GbE was readily available for most of the iSCSI arrays even a year after it was launched in 2002, you don’t see widespread adoption until well into 2006/2007.
Overall a good rebuttal to marketecture with marketecture. 🙂
gChapman,
Thanks for the perspective and I agree that the change from 8b/10b to 64/66b encoding is commonly overlooked.
I must say I’m curious about your statement that 10GbE wont get the same level of capability that FC can deliver? Could you expand on that a bit?
As an ex-Emulex engineer I’m sure your well aware that OVER 3 years ago your company was talking up 1 million IOPS. That was 3 years ago so I would assume that in that period of time the industry has managed to squeek out an additonal 20%. Here is a link to the original article in 2010
http://www.networkcomputing.com/data-center/1-million-iops-a-small-step-for-networks/229502142
I would say the need for 1 meeallllion (in my best Austin Powers voice) IOPS in a CNA ranks right up there with the need for 16 or many cases even 8 Gb FC, but thats another conversation altogether.
Why would the encoding scheme change IOPS?
One thing the encoding scheme changed was that 16 Gbit FC, from my understanding, doesn’t have to run at full 16 Gbits. Through 8 Gb FC, each Gigabit would give you 100 MBytes of throughput, and not 125 MBytes like you do with raw Ethernet. (1,000 / 8 = 125). This is because of the 8/10 encoding, so you lose 20% of each Gigabit.
Because they moved to 64/66 encoding, the overhead is not nearly as high, so you don’t lose 20%. You lose like 3%.
But FC sticks to 100 MBytes per Gigabit, so 16 GBit/s FC is actually 14.6 Gbit/FC. Because 14.6 Gbit still provides 1600 MBytes/s.
So while there is a benefit to moving to 64/66 encoding, the savings are already baked into the standard. That’s my understanding at least, please correct me if I’m wrong.
Apologize if my comment was misleading. The encoding scheme doesn’t change the IOPS, it simply reduces overhead and results in greater efficiency.
I fully understand the ridicule laid at the “1 meelyun iops” claims, but lets be honest, its the standard of measurement that the marketing and technical journalist class live by. I will say this, in testing that we performed, which was backed up by Demartek, the current crop of 16GFC adapters were capable of 400k IOPS on a 8k workload on a single port. If high IO is a requirement for your storage needs, you will have to increase your port count on 8GFC to reach those numbers (by a factor of 5 in many cases). So I say do more with less.
Case in point, look at how VMware reaches 1 Million IOPS on a virtual machine, its with six 8GFC adapters working together. Not a realistic situation for most, but I do see many instances of four and six 8GFC adapters being placed into quad socket boxes. If we can deliver the same performance with 1/4th the number of adapters then we are doing the customer a service and reducing their power, heat, and cable footprint. I say think bigger. Think outside a few hosts here and there. Think thousands.
16GFC isn’t a move to higher bandwidth, its a move to higher efficiency, lower latency, and better overall response times for workloads. PCIe3.0 helps as well, but the fact remains that the current 8GFC chip designs are nearly 7 years old. Modern 16GFC asics are built off multicore architectures and are capable of far more than simple FC capabilities. Combo cards that do 10G as well as 16GFC provide a best case scenario for many organizations looking for increased redundancy without having to stuff twice the number of cards in their servers. Wasn’t that one of the value adds of “convergence” in the first place?
I think there are very few actual workloads that can take advantage of the advances made in FC and Ethernet. As things speed up, things start to break. 40GbE has its place, but its most likely not in the server rack space, perhaps blades where greater consolidation of physical nodes can take advantage of the increased bandwidth available. Then again, look at the price points needed to deploy 40GbE and then see if it makes sense. I think the ROI still isn’t there yet.
Interesting response concerning Brocade, a few comments…
I doubt that Brocade is trying to confuse or befuddle customers by calling 16GFC -> Gen5, nor do I believe that Brocade is trying to convince customers that it has developed some version of FC outside of the standards bodies. Gen5 FC is standards based, at least as much as FC has been up to now. There has never been supported E_Port interoperability between the two companies, so what’s the difference if it is or not? Clearly, it has to work with the end devices. The feature set included with 16GFC products is Brocade’s proprietary value add and has nothing to do with standards and the reason why some customers buy Brocade. To be fair, the same is true with Cisco MDS. I think the purpose of GenX marketing is straight forward, “don’t buy based on port speed alone, buy based on product feature set”, and Gen5 has advanced features over Gen4.
When you think about next Gen products, don’t think “BW”. BW is not the issue or even what is leading the sales effort. I’ve never had an SE come in and tell me I need twice as much BW. That’s ridiculous. But there are things I do need. BW is merely the side effect of technology marching forward, Moore’s Law kind of thing. Think “features and functionality”, which is better described by the generation than by the maximum port BW. Brocade’s Gen X has always had the lowest switching latency (measured in nanoseconds) and highest IOPS, hands down and will continue to do so with Gen 5, 6… Considering bit serialization time onto the wire is significantly less as port speed increases. You can say Gen 5 provides faster overall response times in an environment that requires many IOPS before the user’s application responds. Additionally, Brocade’s Gen 5 has mechanisms that prevent common workloads in parallel from getting trounced upon, consider Virtual Circuits, QoS… for instance.
16 GFC is coming like it or not, Brocade is always the first and the industry closely follows. IBM will come out with 16 Gbps on the mainframe. All the major arrays will have 16GFC. As for 40GE FCoE/iSCSI, let’s see the feature sets and relative robustness of architecture that goes with that speed bump? It was a long wait for 10GE to arrive on any array and I suspect that 40GE is not coming within the next 3 years from those very same companies.
Clearly, there is no obvious comparison between 16GFC and 40GE. Why would you even say that? To me, that seems silly. In our shop, if we wanted to move to 16GFC that is relatively easy in both connectivity and migration of devices. If we wanted to move towards 40GE, or even 10GE, FCoE or iSCSI, that would be monumentally difficult and unlikely to happen. To be honest, FCoE is undesirable for many reasons, some not technical in nature (i.e., cultural, operations, no clear ROI). We have a better chance of moving to NAS vs. FCoE, just to put it in perspective.
Your comment about feature sets being the same from one speed to another may be true for MDS equipment or limiting the scope to the FCP itself, but it is not true for Brocade products. Each Gen has significant new features. Making an argument that the scope of features for advancing generations of products is limited to INCITS standards is not really relevant and not an implication that Brocade is making, or should make. This argument of yours is quite a stretch to discredit them and all your effort about INCITS explanations are not really the point, in my opinion.
About Brocade and FCoE market share…
Dell’Oro Group explains the whole sordid mess and why that firm took corrective measures:
“NOTES: We began including FCoE capable products in our SAN Market tables in 2009 in order to reflect how FC was converting to FCoE. However, we recently discovered that only a small portion of FCoE products are actually being deployed to carry SAN traffic. The majority of FCoE products are being deployed to carry LAN traffic and therefore to reflect the sales performance of these products vis-à-vis FC products is misleading. Effective January 2012, we have removed FCoE switches, controllers and adapters from the total SAN Market tables, and placed the data into the Appendices. We plan to investigate and analyze the portion of FCoE products that are being deployed for SAN.”
Cisco lost great credibility with us over this debacle and frankly, I highly doubt any claims Cisco makes concerning market share are true. I think your claim of Brocade having 1% FCoE market share is bupkus and I would certainly deploy Brocade VDX/VCS 6730 for FCoE over Nexus anytime, if we were to ever do any such thing.
Hello CoreEdge,
Thanks for taking the time to write such a detail reply. You may be surprised to note that I actually agree with the bulk of what you’ve written. There are, however, some things that I would like to clarify as I’m not sure that you gleaned my true intention from the post.
There is a difference between being “standards-based” (which is, as I said in the post, not an issue at all; Brocade marketing can do whatever it wishes) and being “a standard.” The quote identified above seems to indicate that the intention of Brocade to blur the line as to what is or is not standardized went too far, to the point where even a savvy storage tech writer stepped across it.
See, I don’t think of “Generations” as bandwidth. I think of hardware versions. But the blog post that Brocade put out, in addition to the press release, in addition to the Register article, makes it very clear that they have defined the term “Generation” with the speed delineations.
Yes, yes it is. In fact, Brocade has been saying this for two years now. Cisco has always said that we supported and believed in Fibre Channel (and 16GFC in particular), but in 2011 we were getting more requests for better optimization of links and convergence than we were for higher bandwidth FC links.
So where are the 16G arrays? Coming, yes, as you point out. But why weren’t they available when Brocade released their forklift replacement chassis? In fact, why weren’t they available within two years of their 16GFC chassis?
Meanwhile, you state that it “was a long wait for 10GE to arrive on any array,” but the first 10Gb FCoE array was available in November 2008, less than 6 months after the Nexus 5020 was released (actually, more like three-and-a-half, IIRC). Since that time we have high-density arrays for FCoE and extremely broad support for multiple types of deployments – everything from Access Layer convergence to Multihop Topologies with FC-based storage to, yes, even end-to-end FCoE storage networks.
Here we are, though, two years later, and we have been waiting so long Brocade is already talking about 32G next year! I mean, seriously? It took this long to get 16G arrays to market and already they’re hinting at 32?
Ah… and therein lies the rub, doesn’t it? For Brocade it’s easier to equate the speed with a “Generation” because every time they talk about a new speed they require a new chassis. So when the first MDS released in 2002 can run FCoE line cards released in 2011, what generation might that be, exactly? After all, Brocade’s definition of “Generations” is so vague I’d honestly have no idea how to adopt the moniker “industry wide,” as they seem to want to be done.
In this case, it appears that you did not read the Register article, or even the quote I included above, very closely.
You’ll note that they don’t talk about the “5th Generation” switch. Everywhere they have this discussion they are talking about Fibre Channel – the protocol – not their equipment.
Quite frankly, it’s not exactly “a stretch” on my part. Take a look at some of the twitter stream after Brocade’s initial blog post, or even EtherealMind’s response, and you can easily see that I am not alone in my interpretation.
I’m afraid you lost me here. What “debacle” are you referring to?
Well, you make a pretty broad statement about Dell ‘Oro, but as I happen to be on the Dell ‘Oro calls and receive their reports, I can tell you that they do report the FCoE SAN Switching Market Share, and this is a number that is consistent with their analysis.
Really? Wow, I have to say that surprises me. 🙂
Kidding aside, the subject of this post was very specific. There is no comparison about products here, or implementations, or even design philosophies. I did not say that 16G “wasn’t going to happen” or that Brocade doesn’t try to offer value to their customers. Nor did I say that they shouldn’t continue to develop products at faster and faster speeds.
What I said was that I observed a marketing ploy that was amusing until they started messing around with calling it a ‘standard.’ “Truth in advertising” and all that, you know. The standards are there for a reason, people do use them to make decisions and determinations, even if you do not happen to count yourself among them. For that reason (and the ones I enumerated above) we must avoid confusion and ensure they don’t move from “marketecture” into “blatant intent to mislead people.”
Perhaps we can agree that no matter how much we like our vendors we should hold them to a certain standard (pun intended) of reality.
Thanks again for taking the time to write.
J Metz…I wonder why arrays seem to lag behind switches/adapters. Seems this has always been the case.
Also, Brocade’s 16g refresh was NOT a forklift replacement…blades insert right into the DCX.
It’s always been that way, as far as I know, that arrays come later than the adapters. *shrug* I suppose we’ll have to ask the array vendors to chime in here if they wish to.
Regarding the 16G chassis, it’s been a while so I went back and checked. According to FOS 7.0 Admin guide, 16G did, in fact, require a forklift upgrade.
For some reason, the screenshot won’t upload. Gotta love wordpress, I guess.
Check out page 47. of the Fabric OS Administrator’s Guide. You’ll see that it’s quite explicit:
“The core blades for each platform are not interchangeable or hot-swappable with the core blades for any other platform. If you try to interchange the blades they become faulty.”
I guess it depends on the size of your forklift. I meant the new gen 5 blades work with existing backplane and chassis.
Very succinct and analytical Post! Addressing what’s standards and what’s not in the rapidly growing storage market is of paramount importance. Thank you!
santanu
Is it the same Dell’Oro that stated in 2009:
Networking market research firm Dell’Oro Group Inc. predicts 2011 will be the tipping point when revenue from Fibre Channel over Ethernet (FCoE) storage devices outgrows Fibre
… humhummm
Is it the same report where you can find the statement:
Only 20% of FCOE DC switch ports are actually moving storage traffic ??