SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iFCP as an IP Storage Work Item



    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
    > 
    


Home

Last updated: Tue Sep 04 01:05:59 2001
6315 messages in chronological order