This protocol has got only 10-15% of useful payload, so basically what you get on 10GbE link is effectively only 1-1.5Gbps usefull data bandwidth. You need FCoE, FC and SCSI offload to get this data out. To me, this seems to be one really very hot microprocessor.

On the other hand, if you have 8Gbps FC, you get around 40-50% usefull payload, which gets you 3-4Gbps bandwidth.

FCoE is just some kind of mixture protocol that’s trying to be some sort of unified protocol, but it’s problem is that it consists of 3 different protocols (IP, FC, SCSI) just enlarging it’s frame size with unneccessery information. This is a step backwards.

What we’d like to see is a unified protocol that has got all the good stuff from all 3 mentioned protocols. Cheap as IP, lossless as FC and whatever SCSI is good for. And the most important part – to be compatibile with all mentioned protocols as well as efficient in terms of having high payload ratio.

Thanks for adding to the discussion.

Im pretty sure I mention DCB in a couple of my posts. However, I dont use the term when refering to DCE/CEE for the same reason I dont refer to FCoE as FC-BB_E….. OK its not exactly the same thing we’re talking about, but I think the term Enhanced Ethernet works and helps the conversation flow better.

BTW I was not aware that CEE was an IBM trademark – are you sure about that?  I see that Cisco are no longer using the term DCE due to the confusion it causes and are now using CEE.  Suppose I will start using CEE now.

Interesting point re FCoE being a transition technology for moving so called legacy FC to iSCSI. Im not totally opposed to that train of thought, although I know EMC have announcednative FCoE connetivity for CLARiiON expected next year, so Im not so sure Id bet the house on it.

Secondly, you do NOT REQUIRE an DCB enabled switch to run FCoE, it will work on any Ethernet switch, but you won’t have any FC functions. The FC switch functions still need to be somewhere in your network. But for best results, you SHOULD run an FCoE enabled switch to get the supposedly new QoS mechanisms, and a non blocking switch fabric (as Brad talks about).

Oh, and for the record, I regard FCoE as a transition mechanism for legacy FC storage to move to fully IP (aka iSCSI), over the next five years. As such, it is likely to be an interim and short lived technology and I won’t be spending much time on it. There is a lot of hype around it from the so-called Cloud Computing boosters, not a lot of adoption or use, and I still question whether it will last. Cisco has duped Brocade into playing in the FCoE market, thus boosting sales of routers and switches and avoiding having to be Number 2 in the Storage market.

Read through your post earlier this week.  Found it very enlightening, thanks for taking the time to share it.

Saw some requests for TRILL info in the comments, and happened across this today:

http://etherealmind.com/trill-introduction-review-overview-why-what-how/

Maybe that’ll satisfy some of the requests until you have a chance to get to your article on TRILL

I find it fascinating that things I’ve been considering Layer 3 issues (multipathing, routing protocols) are moving down into Layer 2.  Perhaps that merely shows my ignorance

Regards

I plan on making this a series of posts on various aspects of FCoE and the underpinning technologies.  So to answer your question….. hopefully this site will help you learn more.  Keep an eye out for more related posts in the future.

Alex,

I’ll put together something on FCoE versus iSCSI on DCE/CEE.  So many things things to discuss!

David,

It will become evident and be discussed in further posts, but for now the secret sauce is in the losslessness of the Enhanced Ethernet.  Congestion should not occur and therefore FCoE frames not dropped.  Although I know frame drops can occur for other reasons such as CRC errors from transmission errors.  However, with FCoE networks being short run within the DC over cables etc rated with excellent bit error rates these are not a factor.  ETS allows for bandwidth allocation etc.  But I plan on discussing them all in detail in future posts……

Nigel