Around the Storage Block Blog
Find out about all things data storage from Around the Storage Block at HP Communities.

FCoE and an interoperability debate with Cisco

CartoonCalvin100X100.JPG By Calvin Zito, aka @HPStorageGuy

I just noticed a post by my colleague on the HP BladeSystem team Ken Henault.  Ken has an article titled This is not the 10Gb network you're looking for.   In light of the last post we have from our StorageWorks FCoE product manager David Lawrence, I thought it was worth a short post to point you to Ken's article and point out the debate on the FCoE standard that's happening in the comments of that post. 

 

If you look at the many comments on Ken's article, they center on how FCoE will handle congestion.   I saw lots of back and forth initially questioning why the QCN protocol (a protocol that will handle congestion for an end-to-end FCoE solution) is needed.  It looks to me as though Cisco is diverging from the FCoE standard to do there own thing - or maybe they don't think it's needed.   HP's positition is to wait for the chips needed to run QCN.  One of Ken's coments helped to make this a bit more clear, "The purpose of QCN is to push congestion to the edge of the network, and keep it from propagating through the core.  A typical Ethernet network has many points of over subscription, and each one of them can become a point of congestion."

 

I'm not clear if Cisco has implemented something on their own to address this congestion or just don't think it's required at all.  I don't claim to be an FCoE expert but seems to me they're rushing customers to buy into their implementation (can you say lock-in).  I'm guessing they'll claim their experts in the space and they don't see it as a problem but I can't help but wonder how things will work out when hardware that uses the QCN protocol is on a Cisco FCoE network.   Are they creating a future interoperability nightmare?

 

Editor's note: This article was originally posted on June 11 on our old blog platform and recreated on our new blog platform on 6/18.  I've also manually added the comments that were left on the old platform.

Labels: FCoE| QNC
Comments
‎06-19-2010 06:36 AM - edited ‎06-19-2010 06:37 AM

Editor's Note: These comments were manually added back as they did not get moved over with the migration of our blog platform.

 

Stuart Miniman   Orginally posted on June 11

 

 

Calvin,

The standard for QCN is done.  That being said, from every vendor that I spoke to it looked to be the farthest out on everyone's roadmap (first the link-level DCB pieces of PFC, ETS and DCBX, then L2MP - TRILL for most).  With proper architecture, congestion management isn't a high priority item.

It seems we're getting into arguments on what is REQUIRED by the standard - in the T11 standard, you must use Ethernet (no special requirements made) - from a practical standpoint, nobody is going to deploy w/o being a lossless environment.  

 

We can create multi-hop environments for FCoE with FC-BB-5 and only the link-level DCB pieces.  Everything else is a potential enhancement for performance.

 

Stu

 

======================================================

 

Joe Onisick  Originally posted June 10

 

Calvin,

 

Again this goes back to the fact that FCoE is just moving FC frames by placing L2-4 FC into Ethernet L1&2 frames.  As FC does not have a standard for network congestion to push congestion to the edge why would FCoE? 

 

The point of confusion here is that DCB and FCoE are seperate standards.  DCB is a set of tolls that enhance Ethernet for the purpose of converging networks.  This includes, but is not limited to FCoE.  Think iSCSI, NFS, CIFS, HPC, RDMA, etc.  DCB can be used for any or all of these. 

 

The requirements to run FCoE are a 10GE network and jumbo frames to avoid fragmentation.  DCB is a set of tools available but not required) to improve FCoE performance. 

 

The critical components of DCB for FCoE performance in both edge and multi-hop networks are ETS and PFC.  These allow treatment of fibre channel frames as lossless on Ethernet networks and provide badnwidth guarantees to those frames.

 

I think this whole argument has gotten fairly out of hand.  You and Ken definitely know your stuff, as do Brad, Dave, and Frank who commented on the other post.  Cisco is definitely not currently implementing QCN, so the real question is will customers be missing something without it?

 

The answer to that is FCoE is just another way to transport FC Class 3 data.  There is no current end-to-end standard for FC class 3 so we won't necessarly need it in FCoE.

 

That being said as FCoE becomes more widely adopted and more robust networks are built QCN will be a fantastic optional feature.  Even Cisco knows this (they have a proprietary protocol called (FCC) on the MDS line that does a similiar thing.  That being said it is not widely used because it isn't needed. 

 

Remember that we typically build FC networks in 1-3 hops, most commonly 2.  In a 2-hop core edge network congestion management outside buffer-to-buffer credits or PFC are not really necessary.  When we build FCoE networks we could potentially push FCoE frames over all of our Ethernet hops, but in reality we won't (see iSCSI best practices for instance.)

 

Either way it's definitely a good discussion and I'll definitely be following your blog and the HP blogs here.  Competition between vendors ends up as better product for the customer ;-)  Thanks to you and Ken for the posts.

 

Joe

 

=====================================================

 

 

 

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
25+ years experience around HP Storage. The go-to guy for news and views on all things storage..


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation