Re: iFCP as an IP Storage Work Item

[Matt Wakeley <matt_wakeley@agilent.com>]

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

Wayland Jeong wrote:
> 
> 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:Stephen.Byan@quantum.com]
> Sent: Thursday, January 04, 2001 5:47 AM
> To: 'ips@ece.cmu.edu'
> 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:terrell@troikanetworks.com]
> > 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
> >