In reply to TonyAtDell (First Name).

Hi Tony, thanks for taking the time to reply. :)

Also, thanks for confirming much of what I wrote. Obviously, I agree with the first five paragraphs of your reply. :) To the rest, let me try to answer your questions in turn.

I would ask your to clarify your position that iSCSI is a “converged solution” by definition. Simply because it leverages a common standard transport protocol, does not automatically mean that it should be converged with non-storage traffic.

Converged Networks typically means that you are taking storage and LAN and running it on the same transport mechanism, as opposed to separate networks (such as native FC and Ethernet LAN). NAS, iSCSI, SMB, etc. allow customers to have different types of traffic running over Ethernet, but it's the block-storage that originally took its own switches or links that now can be run simultaneously over the same ones.

We believe that “converged networks” = “data center bridged” networks

I think the question must be raised - which part of DCB? As I mention above, there are multiple documents in DCB and not all of them are required for any given solution. You do not need, for instance, to run the DCB version of DCBX (CEE version works just fine, considering it's what every vendor uses right now). QCN is not a requirement. Technically non-ETS QoS would work equally fine for sharing iSCSI traffic as well as anything else on the same link.

Saying that Converged Networks "equal" DCB is like saying that Streets = Transportation. Yes, there is an intersection there, but as described above, you can use elements of one without requiring everything else that could possibly fall under that category (streets don't need to accommodate trains, Airbus 380s, etc.). As you point out, iSCSI works just fine and dandy on higher bandwidth networks without the need for interference at Layer 2 (which is where PFC lives).

We would not recommend trying to merge storage and non-storage traffic in any situation without the level of QoS control that DCB can provide.

IIRC, ETS doesn't define the mechanism by which bandwidth groups are defined or allocated. It just so happens that the way vendors do this is through QoS.

The ability to actively manage iSCSI via ETS and PFC is just as important to iSCSI as it is for FCoE.

Why? The logical corollary is that iSCSI doesn't work without PFC. PFC is 100% completely independent of ETS/QoS. They have absolutely nothing to do with each other. So, if we were not using ETS/QoS on a link (that is, only had iSCSI traffic), why would you "need" to have PFC? As it turns out, the millions of iSCSI ports that are available on the market do not use PFC, and since there is no difference (from a L3/L4 perspective) between 1GbE, 10GbE, 40GbE or 100GbE, why does iSCSI suddenly have to change it's behavior when the L1 parameters are changed? Isn't that the whole purpose of a layered system?

Moreover, FCoE has a explicit requirement for lossless behavior. It's written into the standard spec (FC-BB-5). Not so for iSCSI. And since we're talking about the use of standards (i.e., DCB), those specifics can make a huge difference.

Thanks for the link to the white paper. I look forward to reading it. :)

Best,
J