In reply to Tony Ansley.

Hey Tony, more great stuff here.

I think the confusion is in the idea that because you CAN converged traffic does not necessarily mean you SHOULD

A favorite refrain of mine. :)

I would argue VLANs do nothing to ensure QoS…they only isolate traffic logically

Yes, precisely. But it works, and in some cases it works well (depending on the level of traffic you're talking about). Remember it's only when the aggregate bandwidth is above 10G that there is contention for resources. If you never push that much bandwidth guaranteeing a minimum is a pointless exercise. Host links are undersubscribed as it is (hence the reason why converging them often makes sense).

I'm going to conflate two things that you wrote into the same quote for simplicity sake:

Without having a mechanisme such as ETS to control bandwidth and PFC to ensure that the other traffic streams are not the cause of a blocked path, there is no way to guarantee the QoS of the iSCSI stream.... As you state in the previous quote above, the mechanism to manage ETS and ensure that buffers don’t become saturated does involve PFC. Many switch vendors use PFC to throttle their upstream senders to ensure that the switch can internally honor the ETS limitations.

I'm sorry, but that's simply not the way that PFC works. Priority Flow Control has absolutely nothing to do with managing buffers. The word "priority" in this sense is not the same thing as "priority" in a QoS sense. QoS manages the priority (i.e., the "importance") of traffic in a variety of possibilities. PFC determines whether or not to institute PAUSE on a priority (i.e., an 802.1Qp "lane"). It is a sad fact that the same word is used to indicate two completely different things, but there you go. :(

The relationship with PFC and buffers can best be understood as a "read-only" mechanism. That is, when a "high water mark" is reached as the buffers fill, PFC is initiated to send a PAUSE to the sending device in enough time to prevent dropped frames while still allowing for the frames in flight to be delivered. This happens on dedicated lossless links (e.g., the FCoE line card on the MDS is FCoE-only, which uses PFC but has no need for QoS because there is only one traffic type).

Personally, I can't speak with any confidence about the way other vendors implement PFC and ETS, though. The two standards documents are completely independent of one another, and I don't know for sure if/that anyone else creates such dependencies. It seems to me that if that is the case, though, then they are using the two technologies in a way that wasn't intended by the standards working group. If they had been designed to be co-related they would have been part of the same document, like ETS and DCBX (as you point out).

I would contend that all storage traffic should be lossless.

Really? All storage? SMB, NFS and CIFS too? It seems to me that this would be treating all storage as equal, when it really isn't. I'm curious as to whether or not you loathed iSCSI until PFC came around. :)

Without PFC (or even 802.3x flow control), relying on TCP – and its longer timeouts – to provide “guaranteed delivery” via TCP Retransmits, is a performance killer.

If that's the case, why use TCP at all? After all, TCP was designed because IP had no such guarantee. If you're looking at lossless behavior in your storage why bother with additional upper layer protocols that can increase latency?

Bottom line, is that iSCSI can receive all of the same benefits from ETS, PFC, QCN, and DCBx (assuming the iscsi devices support these standards) as FCoE or RDMAoE.

You'll note in my conclusion of the post that I agree with you here. Key word here is "can." There are distinct advantages to each of these technologies, and there is a fit for them in certain implications. Certain, but not all. Some of those advantages include cost, ease of use, performance, skill sets, tool kits, etc. Ultimately if customers create iSCSI environments without considering the unintended consequences (especially at massive scale), they can wind up worse off.

More to the point, though, knowing what is required and knowing what is recommended are two completely different issues. Showing my bias a little here, it does customers a disservice to equate the two. Sort of like going to a mechanic and he tells you that an engine replacement is "required" just because you'd get better performance. :)

By the way, sorry my quotes don’t look as good as yours

One of the advantages of having access to the post admin tools. :)

Thanks again!