Slashdot Mirror
HyperSCSI Examined
An anonymous reader writes "Eugenie Larson of byteandswitch.com has published a brief article that reviews the HyperSCSI protocol, which like iSCSI allows for an IP based san. The twist of HyperSCSI is that it's opensource, and runs over raw ethernet, avoiding the overhead of TCP/IP. The article has some comments from early adopters of HyperSCSI, as well as some comments from top vendors in the iSCSI industry."
scuzzy wuzzy was a bear...
why is there an article on this, i mean linux wont support it for another 2 years lol
With all it's error correction and what not! Who needs that for data stoage?
I read somewhere that it's like 5 times faster than SCSI over TCP/IP. Is it true? And how great is the sacrifice of not using TCP/IP? I mean, what doesn't support Ethernet these days?
I, for one, welcome our new raw ethernet running overlords.
The summary says "IP based" then "without the overhead of TCP/IP" and then "raw ethernet".
Which one?
Can't be both IP based and raw ethernet at the same time.
You don't expect us to RTFA do you?
"avoiding the overhead of TCP/IP"
yet you can tunnel IP inside of it... adding a layer of overhead for IP.
I like the idea. Ethernet hardware is dirt cheap and fast. What it needs is a cheap IDE bridge board. That would let you put some IDE drives in an external enclosure and plug them into the local LAN.
Mea navis aericumbens anguillis abundat
and
Mmmm.. beer can with motor.If you look go to the MCSA site and look at the HyperSCSI FAQ, it does implement reliability and flow control, just not in the same manner as TCP.
The only technical negative side I can (at this time) is that because the implementation isn't over IP, you can't traverse a router. This usually isn't a problem but could cause some inflexibility in larger deployments.
What is this?
And this is a technology breakthrough? I wouldn't want my data travelling down a wire with no error recovery no matter how small the error rate.
From excellent karma to terible karma with a single +5 funny post...
and
obviously, it's so when linux does support it, legions of slashbots can complain about the duplicate stories!
From the article:
Read, L
Two big disadvantages:
First, Ethernet can't be routed, so hyperSCSI isn't going to be nearly as flexible as iSCSI. This is the reason that just about everything that might want to be routed is usually carried over IP (and TCP and UDP and other stuff on top of IP). Straight ethernet is for stuff like ARP that really doesn't want to leave a network segment.
Of course, one could reasonably do something hyperSCSI-like across IP, and still save the TCP overhead. (Consider that in a low-loss short-hop environment, NFS over UDP generally outperforms NFS over TCP). The problem here is that SCSI was never ever intended to run well over a lossy transport, and it doesn't. That seems a serious objection to running SCSI over both non-routable and non-reliable ethernet and routable but still non-reliable IP.
C'mon, there's a reason why people use TCP....
And why iSCSI chose TCP as the transport....
Vanilla Ethernet can be extremely reliable, without any additional layered protocols. I would be much more concerned about the reliability of the installation's AC power supply and distribution system.
Mea navis aericumbens anguillis abundat
But I'd prefer to use it over gigabit ethernet, or at the very least a separate ethernet device than the one I use for me lan.
Can multiple computers access the same drives through this?
On another note, is it possible to network over traditional SCSI, by changing the SCSI card ID's to make them co-operate on the same chain? Does an implementation of this exist in Linux, *BSD, or Solaris?
You can't judge a book by the way it wears its hair.
SCSI is dead and it should stay dead. We have USB 2 and Serial ATA. And it's enough. We don't need any more data transfer standards.
Thank you and have a nice day.
Use loose and fast HyperSCSI on your local segment where it's possible, and use a concentrator that translates into iSCSI over IPSEC for secure WAN connectivity.
That way you only need to buy one TOE card per WAN edge. Those can get expensive!
Fuck Beta. Fuck Dice
This is great for folks that want to be locked into a single vendor without any path to get out
Didn't the article state that HyperSCSI is GPL and runs on Linux? What the fuck is this guy talking about?
tuned for SCSI commands and data transfers. This is the particularly interesting part of the protocol. It assumes you're going to be doing bulk transfers, and lets both ends negotiate windows for performance (as opposed to using a sliding scheme).
As I see it, the real problems:
- SMP "experimentally" supported
- client and server can't coexist on same box
- client model is not decoupled enough from the server (a server going down can mean the client could crash)
It appears the driver software needs some work properly implementing what seems to be a nifty protocol. And they want to port it to Solaris. I think they should get the locking and stability down first.
Fuck Beta. Fuck Dice
And it is forbidden to use this with Linux. Besides, Linux is pirated software (from SCO) and you're not allowed to use it anyways. Face the facts, you fucks!
The NICs are cheap and the prices of the switches are dropping. I don't think it will be that long before gigabit Ethernet starts to push 100 Mbit Ethernet out of the market.
Mea navis aericumbens anguillis abundat
If it is truly raw ethernet, this means that you cannot route it. On most current networks, you probably wouldn't want to because of latency issues, but, on networks with 1 gig or 10 gig links, latency should not be a problem. So, if it does use raw ethernet, this is actually a limitation of it, not a benefit.
Need Free Juniper/NetScreen Support? JuniperForum
Fiber Channel SANs aren't based on IP either, yet people manage to do off site replication with them.
I don't know how far away you want to put your off-site backup, but Cisco have been selling a GBIC (Gigabit Interface Converter ? Too many FLAs for my head these days), which they've been calling 1000BaseZX, which will send an GigE signal around 90 Kilometers over single mode fibre.
Even Full Duplex Fast Ethernet over multi-mode fibre will go 2 Kilometers.
You can build some really big ethernet networks these days. I don't think the non-IP thing is all that much of an issue.
Although the idea of using cheap commodity equipment like ethernet is to rationalise multiple networks down to a single IP network, there are also good reasons to using commodity ethernet to build a separate network for your storage, security being the main one. It probably wouldn't be too good to have CodeRed or other worms of its ilk infecting your storage network.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
UDP is ideal for latency sensitive data, like real-time telemetry. It does require that you have excess bandwidth or control over who has access to the network if you want to avoid dropped packets.
Mea navis aericumbens anguillis abundat
An therein lies your problem. You just can't get around the human error factor. People incorrectly install equipment and configuration mistakes abound in a corporate environment.
From excellent karma to terible karma with a single +5 funny post...
I wrote LEGITIMATE CRITICISM and you shutted me down like that? It's SO NASTY!!!!!
A CURSE shall be on your head FOREVER!!! Those spake zarathustrada!
Pervertus
The lessons of NFS are being ignored, and I'd expect HyperSCSI to die when it hits the same limitations.
NFS started out UDP-based, and moved toward TCP with NFSv3. Why? Because having all that error correction done at the network layer made for a better product; TCP does all the work to insure packets aren't lost or out-of-order. UDP doesn't, and the NFS application layer had to handle it, making it slower, more painful, and a duplication of effort better spent elsewhere.
The industry guys are almost right on this one. It isn't a beer can with a motor; it's a beer can with an M-80. Fun to watch when it works right, damn painful if you screw it up.
How do SANS based on such things as HyperSCSI handle cuoncurrent filesystem accesses by mutiple different machines, since the device at the other end is just acting as a disk, and the host has to maintain filesystem integrity?
Saying that HyperSCSI is open source or HyperSCSI is under the GPL is pretty meaningless; those concepts don't apply to protocols. A HyperSCSI implementation is under the GPL, but so what? There are open source iSCSI implementations, too.
Come back and troll when SATA has doubled in speed, and when I can plug at least 15 drives into a card.
Hey, I plugged 15 SATA drives to my ass and had no problem with that at all. I don't know about you, but I ain't gonna try that with SCSI drives.
HyperSCSI, huh?
Well, let's just add that to SCSI, SCSI 2, Fast SCSI, Wide SCSI, Fast Wide SCSI, Narrow SCSI, Ultra SCSI (aka SCSI 3), Ultra-2 SCSI, Ultra-3 SCSI (Ultra-160 SCSI to some), Ultra-320 SCSI and iSCSI. (I'm sure I've missed something out.)
So what's next for this party? UberSCSI? 1337SCSI? TheOneRingSCSI?
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Hi. My name is Rob. I'm an attractive young man. I'm a few years over 20 and I work on a geek website. I would like to share with you an incident from a year ago that changed my life.
It was late at night and I was alone in the basement of the geek compound. I'd lost track of the time, but was sure it was at least 1 or 2 AM. I'd lost track of time because I was so busy enjoying my collection of gay porn. The week before, I had stolen a CD with anal sex videos on it out of Michael's room. I don't think he knew it was missing, yet. He had been very busy censoring people for the past week and just didn't have the time to masturbate.
I was watching a video of a black man giving a blow job to a large asian man when I heard a soft moaning noise. I wasn't sure if it was part of the video or if it was real. It was a middle of the night and I was a bit uneasy about being in the basement, even if nobody dared come within 20 miles of the geek compound because of the horrible odor from the building. Quickly, I paused the video and listened closely.
For several seconds, it was dead quiet, but then I heard the noise again. I was sure it was real and it seemed to be coming from the room across the hall. Now I was quite afraid. I sat as still as possible and I heard a grunting noise coming from the same place. Immediately after, I heard a second grunt. Despite my fear, I quickly made up my mind to go investigate. Even though I was terrified, it was very important to me to be able to masturbate in peace.
I stood up, but I was so afraid, I forgot to pull my pants up. My tiny cock was straight as an arrow and hard as a rock, pointing about two inches in front of me. It was quiet now as I walked toward the doorway, still shaking from fear. The room across the hall was dark, and the hallway in between was lit only by flickering lights on the ceiling. Because the company I work for was (and still is) nearly bankdrupt, there just wasn't enough money to replace the light bulbs.
Slowly I walked to the doorway and out into the hall. It was still dead quiet. I glanced to my left and then to my right. I couldn't see anyone in either direction, so I proceeded into the room opposite mine. The door was open and the intermittent light from the hallway provided the only illumination. There was no sign of anyone in the room from the little I could see.
Suddenly, the silence was broken by another grunt. This time, it was louder and I was sure it was coming from inside the room. The noise startled me, though, and I had already begun to shit myself. I wasn't wearing pants, so I can't really say I shit my pants. But the shit hung down from my asshole as I fumbled along the wall to find the light switch. Another grunt came, this time louder, and it startled me enough that some of my shit hit the floor. I was still shitting myself, though. The smell of fresh shit was usually refreshing to me, but I was so afraid I barely noticed.
Finally, after several seconds, I found the light switch on the wall. While the lights flickered on, I heard the same grunting noise, and was sure it was coming from my right. I looked in that direction and saw piles of dirty clothes along the wall and a closet. The closet door was closed. I was terrified, but I knew I had to inspect.
As I approached the closet, I heard the same noise again. My hand was shaking, but I fought the tremors and swung the door open. To my surprise, I saw Jeff bent over with his pants down. Jon was standing over him with his pants also off and his tiny penis was rock hard and covered with blood.
I was mad. I was furious. How could Jon be doing this with my boyfriend. In my anger, I blew my load all over the closet, and at the same time, let out a huge fart.
"How could you? What the fuck?" I screamed as loud as I could. In my anger, I grabbed Jon's hand and pulled him out of the closet. After that, I grabbed his neck and bent him over. I stepped behind him, and with my bare hands, I tore his asshole open. He let out a scream. In
Never underestimate the bandwidth of a pair of sneakers carrying a hotswappable hard drive jogging down the hallway.
KFG
In looking for a cheap substitute for a FC SAN you don't need or want routing. You're looking a cheap way to implement a local, reliable, high performance fabric. That's all. People like iSCSI because it's compatible with existing infrastructure but they don't stop to think that they won't want to put their server farm storage on the routable corporate net. The problem with ethernet is that it's hard to scale performance with small packet sizes and all the buffering. Work is being done to fix that and it has nothing to do whether it's IP-based or not. Look at InfiniBand and iWarp for what's really important.
you generally prefer this unroutable
It's not really applicable. You need a dedicated network with a high speed backbone, dedicated servers running a Unix to pimp the storage, and you'd be better off with a commercial clustering filesystem (GFS or some such).
;-)
I can see small offices, workgroups, and studios using this to get high-speed storage on line quickly with cheap components.
iSCSI has a better chance of being deployed in the home (of Unix-y types and their unsuspecting kin). I'd say, iSCSI all the way, none of this baby CIFS BS in my house!
Fuck Beta. Fuck Dice
They are not the same, and increasing throughput doesn't necessarily increase latency.
Unroutable is definitely the way to go here.
You're gonna want to go with big packets and such. And you don't want to go through and entire stack just to get your sector.
Think of it this way, unroutable means never having to ARP.
Funny how the drive vendors don't agree with you. SATA is new. It's fast enough and has a roadmap to higher speeds. It's point-to-point design is a major strength over SCSI, you just do understand why. SATA is for inside the box. InfiniBand and iWarp are for outside. SCSI and FC are doomed to the scrap pile. Time is on SATA's side. You'll see.
it's author is Jesse Keating
iSCSI has drivers for every OS you can imagine, written by CISCO, IBM, Microsoft, and released under the GPL. This is from the iscsi sourceforge page.
This implies for instance that one could boot ones diskless workstation from a collocated netapp on another continent, protected by a an IPsec tunnel. While i could do something similar with ethernet layer tunneled over IP, it leads to many complications and difficult debugging. I have personal experiance with this, as this how our company runs its ethernet layer phone system.
It stands for Storage Area Network. Here's a link courtesy of our overlords at Google.
Kill me if you like but Ethernet is NOT the right kind of media for this. Ethernet does not have "guranteed latency". It is not a real time thing--rather best effort thing. I will be happy to run this over a "fixed" latency media but not even think about doing it over ethernet. One of the reason I like firewire ... but I guess this is an apple thing and INTEL will do anything to kill it in the future or come up with other crap like USB.
- People who believe other people have no right to live, got no right to live ...
Actually I'm surprised there isn't FDM Ethernet. There's a lot you can squeeze down an enclosed wire. Just ask the cable TV guys.
Because the IP checksum and TCP checksum occasionally disagree about the packets' validity in real-world routers and operating systems - they are both needed to provide redundancy and robustness. Stevens' TCP/IP Illustrated cites [Mogul 1992] providing counts of checksum errors on a busy NFS server:
Layer Total packets # chksum errs
Ethernet 170,000,000 446
IP 170,000,000 14
UDP 140,000,000 5
TCP 30,000,000 350
Basically, when absolute accuracy is required the more error checking the better.
It is located here.
Well, first off, "HyperSCSI' isnt such. All it is is just a correctionless protocol over ethernet hardware. Really, that's a bad idea. You'd be better off if you used ethernet hardware that sped up IPSEC and related ip protocols.
1: Create 2 networks, one being the normal network, and one being the SAN
2: Use GigE cable on your SAN with the inclusion of advanced Network FS'es like Coda.
3: Provide POP's that connect the external network with the internal SAN/serverNET by way of tunnels and port forwarding. Also offer a way to mount local share by Samba or the network FS'es you use internally. Kerberos and an LDAP would be a STRONG option for maintaining
Back in the day, we called that a "SneakerNet" network.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
The GPL is not specific to Linux. You can have an application built upon Win32 and released under the GPL, and it will not run on Linux. The point of the GPL is not to help any particular operating system, yet to assist software to have a conditional freedom and authority backed by copyright law in recognition that if it were true public domain then it could be "hi-jacked" into another software.
The GPL establishes penalties for people or artificial entities that don't provide the sourcecode of the software, yet the GPL states it is voluntary to accept the GPL and if not accepted then copyright law is the premise for not accepting the GPL's distribution rules. And in copyright law, whoever using the copyrighted software needs the permission of the copyright owner on use of the alleged "software." GPL is a harmless fuzzball, fear the copyright owner.
If you want true freedom, then software would be released anonymously in the Public Domain and the risk is someone could steal the software and claim they own it. An example of a Public Domain work is the Authorized Version Bible aka King James Version Bible of 1611 A.D. All the recent alleged "Bibles" such as "New International Version", "American Standard", "New American Standard", "New King James Version" (false King James AV), and "Century New King James" (false King James AV), and many more are all actualy copyrighted! They are known as false Bibles because in their preface or inserts there is a text from a corporation that establishes conditions of their usage, unlike Public Domain bibles such as the King James Authorized Version Bible and also Gutenberg Bible. Further example, the NIV aka "New International Version" manifests conditions upon the reader: "The NIV text may be quoted and/or reprinted up to and inclusive of one thousand (1,000) verses without express written permission of the publisher, providing the verses quoted do not ammount to more than 50% of a complete book of the Bible nor do the verses quoted comprise more than 50% of the total work in hich they are quoted." In short, the NIV changes the many books of the Bible in such little ways to change the outlook and image of God's message and issues a copyright'd patent proclaiming they own and say how much you can quote without express permition! How long before a alleged "Bible" is released that says you can only read it on Sunday and only upon the permission and interpretation of an alleged "father of the Catholic Church" and you must accept the Catholic Church without condition as the divine authority of all scripture:
"For the Roman pontiff (pope), by reason of his office as VICAR OF CHRIST, and as pastor of the entire Church has full, supreme, and universal POWER over the whole Church, a power which he can always exercise UNHINDERED."
--CATECHISM OF THE CATHOLIC CHURCH, 1994, P. 254 #882
"[W]e hold upon this earth the place of God Almighty."
--POPE LEO XIII
"...We declare, state and define that it is absolutely necessary for the salvation of all human beings that they submit to the Roman Pontiff [pope]."
--POPE BONIFACE VIII, BULL UNUN SANCTUM, 1302
"No person shall preach without the permission of his Superior. All preachers shall explain the Gospel according to the Fathers. They shall not explain futurity or the times of Antichrist!"
--Pope Leo X, 1516
Although I may seem offtopic, my point I try to emphasize is copyrights are evil to the extent they can regulate and infringe upon others by use of truth and law that is vested in the mere essence of man if not written on paper. The GPL uses copyrights for the good of mankind, as if to turn copyrights into a double-edged sword, yet even the GPL can be used for evi
Secured Party, Without Prejudice, UCC 1-207: Creditor
Will you be able to boot from these devices? I don't see any mention of it in the article; I'd imagine you'd need support both in the BIOS and possibly the network card..?
Oh Lord and Master Jesus Christ, I pray you shine light upon this tortured living soul for he hath ommitted the many dimensions of the many flavors of SCSI... Single-Ended (SE), High-Voltage Differential (HVD), and Low-Voltage Diferential (LVD).
;-)
May we all be forgiven.
Secured Party, Without Prejudice, UCC 1-207: Creditor
but it's easier to write kernel code for linux, trust me. ::puts up hands:: All bets are off.
f they can't get that right...
Porting it to Solaris wouldn't fix it. You'd have the same issues, and a whole set of new ones.
Fuck Beta. Fuck Dice
Otherwise you might accidentally release a product that sucks as bad as NFS.
But seriously, NFS is only good for short haul networks. Over those networks, NFS/UDP is faster than NFS/TCP.
So what about long-haul networks? Answer: don't use NFS. NFS is FAR from secure. User management across administrator domains isn't handled either and therefore is all but impossible.
For what NFS is actually good at UDP usually fits the bill better than TCP.
And funny thing, I think you'll find this the case for internet SCSI too. You don't use a sector-by-sector remote block device protocol over long haul networks. It's horribly inefficient. Use a file-based sharing system instead.
I just think there's a horrible misunderstanding as to what this is good for. This is a block device protocol, not a file access protocol. That means that only one client can mount a drive (or technically range of blocks) at a time. A special case is multiple read-only mounters at once. But you have to bar any write access in that case.
So, if you have a protocol that is inefficient over long-latency links regardless of transport and requires a 1:1 match of volumes to users, why do you care whether it works well from cross country?
While UDP clearly was the wrong choice, TCP isn't the right choice either: TCP is a reliable, connection-oriented stream protocol. But for file and device access, you want a reliable connectionless protocol.
There are a number of choices. Plan 9 defined IL for just this purpose, there is SCTP for telephony applications, and several operating systems support RDM ("reliably delivered message"). Maybe people should just start using one of them, rather than reinventing the wheel by building on top of unreliable datagrams or by using protocols with unnecessary overhead.
Borg SCSI: Your hard drive will be assimilated into the Borg SAN.
Anybody got one for SovietRussiaSCSI? (I just woke up...)
NataliePortmanSCSI?
I, for one, welcome my new SCSI overlords!
Regarding this, I really appreciate how you explain me why you're my foe.
And it's understood. "Pervertus" deserves no friends. I just write what's on my mind with almost no filtering whatsoever. And that exact moment I was angry on SCSI (and on big flat cables). And if you look on my journal, you'll see what a nasty entity I am! But still I wish someone would have been my friend....
HP's Graham Smith says:
"Without TCP/IP, it has no real error-recovery mechanism or guarantee that packets get delivered."
But that is wrong. There is error checking in the ethernet hardware and in the SCSI stack. It seems Smith needs to review the basic material, or should have at least read the introductory material. Perhaps the takeaway here is, managers should not be allowed to comment on technical material, or if they do, they should solicit advice from a practicing engineer first.
Smith also dumps on HyperSCSI's scalability, but as far as I can see, it scales exactly as well as any LAN, and for storage that's not bad at all. Besides, being 100% open source, implementing a repeater sitting on a routing box is entirely practical.
As far as Andre's comments go, the article should have disclosed that he peddles an iSCSI stack for a living. More power to him, I'm not criticizing his colorful comments or business scheme, just the journalist's failure to take note of this.
Now, my own opinion: I haven't tried HyperSCSI yet. I have it installed here and by rights I should have given it a thorough workout by now, but mea culpa. So little time, so much to do. Well I'll change that today.
From what I know so far: I like the idea of trimming away unnecessary layers. It's the kind of thing we do in Linux all the time. I like the fact that the whole stack is GPL. It doesn't bother me that disk drives themselves don't support the protocol and are unlikely to in the near future, because you have to put the disks in a box anyway, and that might as well be a Linux box presenting a HyperSCSI interface.
Personally, I think that HyperSCSI is going somewhere. So is iSCSI for that matter: the two protocols serve distinctly different target markets. iSCSI is where the money is because hardware vendors support it. HyperSCSI is where the joy of hacking is because it performs better and it's GPL. The thing is, they both present the same interface to the OS (SCSI) so they are interchangable. It's not an either/or situation at all.
You need to pay careful attention to any technique that increases performance without increasing cost.
Have you got your LWN subscription yet?
I think if you read again, and this time don't assume every poster above you doesn't already know this, you'll see the point they were trying to make.
If this uses it's own Layer 3 protocol (presumably, and for the sake of argument, called HyperSCSI), then it's NOT IP BASED... and the article summary indicated it was IP based, then contradicted itself.
When someone says "TCP/IP" they are referring not to a protocol, but a protocol suite. They are NOT referring to "TCP and UDP ONLY".
So, if you say something is not based on tcp/ip,that indeed DOES mean it does not use IP. Furthermore, saying it uses "raw ethernet" indicates that this uses it's own layer 3 protocol, other than IP.
When someone says "TCP/IP" they are referring to the entire protocol suite, which involves TCP, UDP, ICMP, and other stuff on top of IP.
It does not at all mean that they are using TCP itself.
There is a possibility that you would have a small number of machines in a clustered configuration that are serving a database or other disk intensive task, and who share a large, distributed volume.
:-)
Since HyperSCSI is supposed to help you save money by enabling cheap hardware utility, I'd expect the flexibility to realize something like that to maximize the utility of connection-rich 1U/blade servers available today.
Also, don't you think it might be useful that a member of the disk array could access the whole volume to do maintenance tasks or check for consistency? This could be quite useful for a vendor who wishes to sell self-contained NAS solutions.
And re: the SCSI/FC disconnect property... ethernet protocols are generally disconnect tolerant. I'm not saying HyperSCSI has to have that property (mostly because SCSI protocols don't allow for it), but that doesn't mean the HyperSCSI client driver should cause the system to crash. It shouldn't assume the transport layer is reliable, and there are ways to sense link state, so why not protect the user from failure? Scream at syslog, maybe the sysop will get an email, and could plug it in, umount, save the cluster, save the day.
I can only dream.
Fuck Beta. Fuck Dice
solaris would not tolerate shoddily written re-entrant kernel code. I guarantee a crash so hard you can hear it.
;-)
What was that? Did someone hit my car?!
Oh wait, my Blade just froze up, hmmm...
Some of the SMP-tolerant kernel code in linux gets by on the good graces of the IO-APIC keeping interrupts from coming in too fast... heh. heh.
*cough*
Fuck Beta. Fuck Dice
"IP-like" is not "IP"
if it doesn't use IP, it doesn't work "over IP". Either it's IP, or it is not.
By the way, HyperSCSI is a layer 3 protocol, and it has absolutely nothing to do with IP.
The article summary was mixing up iSCSI (which runs over IP only, using TCP) and HyperSCSI (which is it's own protocol)