SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : LSI Corporation

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Jock Hutchinson who wrote (14627)8/29/1998 11:51:00 AM
From: Jock Hutchinson  Read Replies (1) of 25814
 
Oops! Apparently it requires a pass word--so here is the print of the article.

Alteon, Packet Engines and
Extreme on Gigabit Ethernet
vs. Fibre Channel
How do they stack up for storage area nets?

Network World Fusion, 08/17/98

Following is a list compiled by SAN vendor
StorageTek comparing Fibre Channel (FC) technology
to Gigabit Ethernet (GE) in a number of areas that
relate to storage-area networks. In most cases, FC
seemed to hold an edge over GE. Network World
emailed the list to GE vendors Alteon Networks,
Extreme Networks and Packet Engines. Select
responses are included below.

For the "Packet size" section, StorageTek provided a
lengthy explanation. After that, only a one-liner was
provided stating the relative strengths or weaknesses of
each technology in each category. Responses from the
GE vendors follow in each section.

Packet size

The packet data size for GE is 1.5K bytes.
FC assures delivery so that blocks can be
chained together to create up to a 128M byte
transfer in a single I/O by "sequencing" up to
64,000 2K bit frames per packet. This could
be attempted with GE using more, smaller
packets, but there is no guarantee of in-order
delivery. In a nutshell, GE handles 1.5K byte
blocks and FC enables up to 128M bytes,
making it ideal for large file transfers
associated today with normal backup and
restore.

Extreme Networks:

First, the session layer of any protocol (e.g. - TCP)
guarantees delivery. The TCP/IP suite is so valuable
because it was designed to run on top of any underlying
network structure (Ethernet, FDDI, Token Ring, WAN
links, etc.) FC needed to recreate the functionality of
the standard sessions layers like TCP. This means
when there is a problem with FC, there is a lot less
experience to tap to help solve the problem. It also
means specialized interface drivers have to be written
for any of the machines in the SAN. Using a special
protocol for FC just sounds like more work for
everyone.

Second, there is no Layer-1/2 networking standard that
should ever be responsible for frame sequencing. LAN
standards like Ethernet were designed to be FIFO
systems in order to guarantee that frame sequencing
would go untouched and that this would never be an
issue. Frame sequencing is an issue only for higher
layers and is "hands-off" at Layer-2. This is truly
visible in standards efforts like IEEE802.3AD Link
Aggregation where the proposals on the table all
emphasize the maintenance of frame sequencing to
prevent frame retransmission.

Third, the overhead associated with transmitting
1,500-byte frames on GE in a SAN is 1.7%. This is
based on Ethernet's preamble of 8 bytes, header of 14
bytes and 4-byte trailer (FCS), which is 26 Bytes total
divided by a 1,500-byte payload.

Packet Engines:

Ethernet does have a smaller frame size than FC.
However, in a full-duplex Gigabit Ethernet link, there
is minimal data spacing and packets are streamed
back-to-back very efficiently by comparison with
earlier half-duplex versions of Ethernet. The overall
efficiency of the frame size is very high (greater than
98%). And this slight inefficiency is more than made up
by the fact that Gigabit Ethernet's higher data rate (17%
faster than FC) allows more data to be transferred in
the same time.

Alteon:

It's VERY unusual for packets to arrive out of order in
ANY non-routed Ethernet environment. And even with
routers it's still pretty unusual for the packets to come
out of order. Basically, so long as packet drops are
kept to a minimum the data will flow just fine. The only
usual case for packet drops to happen is when you have
switches and/or routers that have limited buffer space
that receive a burst of NEW connection oriented traffic.
In a connection-oriented environment (TCP) and even
in an NFS/UDP environment the flow control keeps the
network from congesting. Most modern switches
(anything with gigabit Ethernet except for Buffered
Repeaters) will be able to handle large bursts without
too much trouble. You can take a look at any of the
Bradner type tests to verify this.

Protocol Support

FC: I/O and network protocols today: SCSI,
IP, HIPPI, ESCON
GE: Network protocol only

Alteon:

Notice that most of the protocols they support are
channel protocols. That's because FC is really a
glorified channel. The IP support they claim is very
limited in how it can be used and in most FC
environments you either run a channel protocol or a
networking protocol, not both at the same time. Device
management is another big problem. Like in HIPPI,
ARP is not very well supported in FC environments
and this creates tough problems for system
administrators. In a SAN that emulates SCSI this
problem goes away because it's back to being a
channel.

Extreme:

Where are any of these protocols used in an enterprise
network? HIPPI, SCSI and ESCON are never use as
enterprise wide LAN protocols; they are mainly system
level. The use of GE and standard protocols like
TCP/IP in a SAN mean that the SAN can be seamlessly
integrated into an enterprise network, rather than being
an island unto itself.

Additionally, FC file transport protocols are vendor
"proprietary". What is the file transport protocol or
standard used between systems of different vendors?
Although FC may be a standard and allows single
vendor solutions, the interoperability of different
systems is questionable. Will an FC implementation
from SGI work with one from Sun? This is really a
work around for OS implementations that have poor
protocol stacks. Different vendors are working around
them by bypassing them. The real problem is the OS.

Behavior on Congestion

FC: Guaranteed delivery, notification (no
data loss)
GE: Frame discard (data loss)

Alteon: Unless you use 802.3x flow control. Then the
data loss level is, while not guaranteed, extremely
unlikely.

More detail from Packet Engines:

In a switched Gigabit Ethernet network, links use IEEE
802.3x full-duplex operation. This includes link-based
flow control. Systems can be implemented to avoid
frame discard. Notification is the responsibility of
upper level protocols and these will work just as well
over an Ethernet data link as over a Fiber Channel data
link.

Biggest Strength

FC: Flexibility, performance, effective
bandwidth use
GE: "Ethernet" image

Extreme Networks:

I would hardly call FC flexible. How would you
connect a FC SAN to the rest of the network? The
answer is easy with GbE. The simplicity of GbE is that
is offers easy interconnect into any 802 network and
seamless integration with Fast Ethernet and Ethernet
networks. The important of 10/100/1000
integration/migration is that 81% of the client desktops
installed today are connected with Ethernet.

In the past, it is the translations between diverse
protocols and gateways between these protocols that
have imposed performance penalties in data network
infrastructures. It is important to look back at
technologies like IBM bus and tag and the impact that it
had in the migration away from host-based computing
networks to client-server Ethernet based networks.

Packet Engines:

Add flexibility, performance and effective bandwidth
use (full duplex) to the Ethernet side as well, based on
input above.

Biggest weakness

FC: Paradigm shift, high cost
GE: Performance, IP only

Extreme:

GE can deliver one gigabit (1,000M bit/sec)
performance with only 1.7% overhead using standard
frames yielding 983M bit/sec of net throughput! Also,
all GE connections, both switched and shared, are full
duplex, meaning the bandwidth of the link is doubled
and hosts can communicate fully bi-directional. Last
time I looked, FC topped out at 800M bit/sec. Which
one sounds faster?

Also, TCP/IP has never been a weakness. TCP/IP has
been a key enabler of the Internet, the World Wide
Web, and business critical networks all over the
world. TCP/IP has become the protocol of choice in
most networks today. There is an industry wide natural
selection which is converging LAN enterprise
networks on three key ingredients: Ethernet
(10/100/10000), IP as the protocol of choice and
Layer2/Layer3 switching as the means for moving the
protocol around the networks.

Alteon:

It's not really "IP only". You can carry ANY
networking protocol on GE-LAT, AppleTalk, IPX,
SNA, whatever.

Bandwidth Usage

FC: Dedicated, multiplexed, shared,
fractional
GE: Shared

Packet Engines:

The Ethernet standard was extended by IEEE 802.3x,
which was approved in March 1997. 802.3x
standardized full-duplex operation and added
link-based flow control. Gigabit Ethernet can therefore
be shared or dedicated. To our knowledge, no vendors
are building half-duplex (shared) Gigabit Ethernet
products. Therefore all links are capable of full 1G
bit/sec performance.

Max Info Rate

FC: 800M bit/sec
GE:1,000M bit/sec

Typical Max Info Rate(uncongested, or best
you will get)
FC:720M bit/sec
GE:500M bit/sec

Extreme:

Simply not true. Since GE is full duplex in both shared
(buffered repeaters) and switched configurations, there
is no contention. Specifically, there is no CSMA/CD
with GE configurations. This is written up in the
GigNet conference proceeding, July 1998. GbE is
always 1G bit/sec full duplex.

Max Effective Rate(congested)

FC: 400M bit/sec
GE: 300M bit/sec

Packet Engines:

Gigabit Ethernet ships 17% more bits per second than
Fiber Channel. The numbers for info rate are subjective
and subject to confusing manipulation. Generally,
slowdown from maximum speed has little to do with
the network. The usual bottlenecks are in CPU
overhead, bus transfer speeds, software protocol stacks
and interface card design. Since Fiber Channel
numbers are usually obtained from dedicated,
optimized disk subsystems and Gigabit Ethernet
numbers from off-the-shelf (unoptimized) PCs, the FC
numbers often look better. However, we are comparing
apples and oranges. Since all Gigabit Ethernet vendors
are only making full-duplex systems, full wire speed at
1G bit/sec is possible. If you design an optimized
storage system around Gigabit Ethernet, you should get
higher performance.

Distance Between Nodes

FC: 10,000 meters
GE: 440 meters

Packet Engines:

This isn't correct. The 802.3z standard calls for 5,000
meters between nodes on SMF (Single Mode Fiber).
This assumes worst case building wiring specs on the
fiber. Actual fiber today is much better, especially
when coupled with good installation practice such as
fusion splicing. Our off-the-shelf component testing has
shown 22km distances and some tests suggest 35km
with standard LX parts. Additionally, Packet Engines
has 1550 nm extenders now available commercially
that will extend length to over 80km.

Extreme:

Extreme has been shipping 10km-capable Gigabit
Ethernet switches and we also have the ability to
extend Gigabit Ethernet over 100km with our
SummitGBX Gigabit Ethernet Extender product. This
product has successfully launched Gigabit Ethernet
over 134km in trials at British Telecom, UK.

Down
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext