Subject: RE: iFCP as an IP Storage Work Item

From: Wayland Jeong <[email-masked]>
Date: Thu, 4 Jan 2001 07:48:57 -0800

I think there are some misconceptions here. As you probably know, the ANSI
FC standard is a collection of specifications that are thick enough to choke
an elephant. Of that large body of work, only a portion of it has been
implemented in the commercial world. I would guess from your comments that
you are referring to one of the ways that FC attempts to guarantee delivery.
The two most notable mechanisms in FC are buffer-to-buffer credit and
Class-2. 

Now, BB credit is a link-layer concept which ensures that when a FC frame is
sent, it will not be dropped on the floor due to congestion. You can achieve
the same functionality in Ethernet using 802.3x flow control. That said,
BB-credit is a layer below what is encapsulated in iFCP. iFCP encapsulates
FC at frame level and largely does not concern itself with an FC primitives
(frame delimiters are an exception to this).

Fibre Channel has a class of service called Class-2 which provides an ACK
mechanism to guarantee delivery to the end station. It uses frame-level
acknowledgements of received data as well as end-to-end buffer credit. This
level of service ensures that data sent is delivered at the FC peer level.
But, Class-2 was not intended to be a congestion management solution.
Class-2 is an error recovery concept and it will not work well in a lossy
network (i.e. IP networks with congestion management through WRED and such).
Moreover, Class-2 is not generally deployed and the FC industry has largely
settled on Class-3. 

Thus, there is nothing within a FC encapsulated in iFCP environment that
makes this protocol inherently reliable. iFCP specifies TCP as the transport
layer and mFCP uses UDP in conjunction with a well-behaved network.

-----Original Message-----
From: Stephen Byan [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 5:47 AM
To: [email-masked]'
Subject: FW: iFCP as an IP Storage Work Item

-----Original Message-----
From: Stephen Byan 
Sent: Thursday, January 04, 2001 8:40 AM
To: 'Bill Terrell'
Subject: RE: iFCP as an IP Storage Work Item

It's all the FC stuff that lets iFCP work over an unreliable data transport
like UDP. It's redundant when running over TCP/IP.

Regards,
-Steve

> -----Original Message-----
> From: Bill Terrell [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 6:10 PM
> To: 'Stephen Byan'
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> >The downside of this advantage is that native iFCP devices would be
> burdened
> >with greater complexity and cost. I therefor think iFCP 
> should not be an IP
> >Storage work item.
> >
> >Regards,
> >-Steve
> 
> How is a native iFCP endpoint (initiator or target) more 
> complex or costly
> than an iSCSI native endpoint? What are the specific 
> difficulties inherent
> to native iFCP devices versus native iSCSI devices?
> 
> Bill
>

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 09 Jan 2001 14:46:08 -0800

Sorry,

Fibre Channel, does not guarantee delivery.  The main reason is that FC does
not have transport layer as robust as TCP.  A FC ACK simply informs that the
frame was delivered.  FC does not have any reliable mechanism to handle
retransmission when an ACK is not delivered.

-Matt