« FC and FCoE versus iSCSI – “Network-centric” versus “End-Node-centric” provisioning | Main | A thought experiment - The Universal Fabric »

02/16/2012

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Victor

Erik, thank you for that thorough answer. Brilliant, as usual. If it's OK, I would like to add another component to the answer: the popular view. From talking to industry data center architects, in particular those who manage high-performance environments, I think the prevailing view is that FCoE requires DCB to provide a lossless environment and any switch that does not offer ETS will be summarily rejected as an inadequate solution that can place the environment at risk.

Has that been your experience, too?

Digging a bit on the technical side of ETS, my understanding is that ETS does not only provide guaranteed BW, which one can configure today with legacy QoS tools, like Cisco's MQC, but that it will allow a statistical multiplexing type model on top of that. In that model, the traffic types that fall under the ETS Traffic Class (TC-2) and are scheduled according to the ETA algorithm (which I know is not specified in the standard - usually its WRR) will not only be guaranteed a configured BW percentage of the link, but will also be able to have more BW DYNAMICALLY assigned to them as the offered load of the other traffic type drops/fluctuates.

For example, in a scenario in which I have LAN and SAN traffic under the ETS Traffic Class, and the LAN traffic is assigned 60% of the BW and the SAN 40%, that means on a 10G link, the LAN gets 6G and the SAN gets 4G guaranteed. HOWEVER, as I understand the technology, each traffic type will be able to exceed that guaranteed amount of 60 and 40 IF the other traffic class's offered load does not meet its minimum. So, if at time t1, the LAN traffic's offered load is only 2G, not 6G, and the SAN traffic needs to burst, ETS will schedule the SAN traffic such that it can use the 4G that the LAN traffic is not using at that particular time. In short, each traffic type can use the other's BW if they're not using it at a particular type. This is done dynamically.

Is this your understanding of what ETS is and what it does?

Erik Smith

Hi Victor, thanks! Your description matches my understanding of ETS. There's a little bit of additional information in the EMC FCoE TechBook if you're interested.

Victor

Thanks, my good man.

Erwin van Londen

Hi Eric,

I agree. The resilience and reliability of FC has caused a lack of interest (or shortage of development resources, depends how you look at it) in the ULP side of the protocols like SCSI. The networking peeps have eliminated this by building a very resilient routable framework on top of that called TCP/IP. :-)

For this reason SCSI works on TCP/IP but not ethernet. Hence the invention of FCoE. :-)

If you leave out DCB, ETS and PFC I would argue you will find yourself on very thin ice when trying to push channel protocols through a CNA.

Regards,
Erwin

Erik Smith

Hi Erwin, I agree. TCP/IP provides a reliable transport and that block I/O protocols (perhaps most protocols that utilize TCP) require a lossless or seemingly lossless transport in order to function properly.

Regards, Erik

Simon Gordon

As you say all devices in practice require DCBX and pfc to get running by default, some have manual override to allow configuration override something that was in the draft dcb standards but not in the final version. Some but not all devices require ets to e configured as well. Practically the same qos can be achieved without ets through normal l2 cos at the priority level (ets being at the group of priority levels - something many people forget). However in reality I 100% agree with your position that the best practice is clearly DCBX PFC and ETS (and FIP Sooping on any L2 switch).

jason

Hi,Does VN2VN FCoE require DCB Ethernet? and how to config it?

Erik Smith

Hi Jason, all (FC-BB-5 and FC-BB-6) variations of FCoE require a lossless transport, so yes DCB Ethernet is a requirement with VN2VN.

How you configure support for VN2VN is platform dependent. Which CNA, DCB capable switch and Storage plaform are you planning to use?

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)

Disclaimer

  • This is not an official EMC blog.
    The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.