iSCSI learns new tricks

As converged Ethernet based on new data center bridging standards proliferates, iSCSI vendors quickly capitalize on the trend

Many people still believe iSCSI can't cut it in the enterprise, which is better served by Fibre Channel. iSCSI vendors are doing their best to prove that assumption wrong.

Ever since 10Gbps Ethernet arrived, iSCSI has competed in the numbers game -- especially when stacked against 8Gbps Fibre Channel. But raw throughput isn't everything. To win the debate, Fibre Channel partisans simply look down their noses and observe that no Ethernet-based storage protocol, iSCSI included, can compete with FC's inherent performance advantages.

That conclusion still holds true to a certain extent, but the performance gap separating FC and iSCSI keeps narrowing. Eventually, other factors such as ease-of-use and flexibility may be more important. To decide which tool is right for the job, you need a solid feel for what differentiates FC from iSCSI; simply repeating that FC is "faster," while true, glosses over vital distinctions.

Fibre Channel on top

No amount of fancy new technology will change the fundamental difference between the iSCSI and Fibre Channel protocols: Fibre Channel, regardless of the physical media that it runs on, operates as a layer-two (data link) protocol, while iSCSI operates at the layer-seven (application) level.

Though this distinction has a number of ramifications, the most critical one is that Fibre Channel implements its own flow control and error correction mechanisms, while iSCSI depends on equivalent mechanisms built into TCP/IP.

Processing Fibre Channel frames takes significantly less time because TCP and IP headers do not need to be generated and decoded for each frame sent. Since Fibre Channel is a purpose-specific protocol, all frame management is performed in dedicated hardware and thus can operate with far less latency. Meanwhile, since iSCSI depends upon TCP/IP to work, encoding and decoding these headers is a necessary step. Increasingly, it's possible to offload much of this work (such as generating error-correction checksums) into hardware that decreases system CPU load, but some latency is still added.

Second, because of comprehensive built-in flow control mechanisms, Fibre Channel is able to shuffle data across the network without any frame loss due to congestion. This makes Fibre Channel an assured delivery or lossless protocol; unless there's some form of misconfiguration or hardware failure, any frame that goes in one end will come out the other without being lost along the way. If there's too much data to send across the pipe or one side of the conversation can't keep up, flow control mechanisms restrict the amount of data being sent and prevents loss-resulting congestion from occurring.

The same cannot be said for Ethernet, which was originally developed as a best-effort packet delivery protocol, implying that packets will be lost when congestion occurs. Because of that, higher-level protocols (such as TCP) must be able to detect that the loss has taken place and deal with retransmitting the lost data segments. In general, this works well in terms of ensuring the packets are eventually delivered -- there's never an issue of data corruption that can result from packet loss. However, in networks where very large amounts of data are being moved and congestion is frequent, performance can suffer heavily.

1 2 Page 1
Page 1 of 2