SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI error recovery



    There's been a lot of discussion on the list about this
    topic, including the proper use of CmdSN and StatSN
    to respond to errors including those detected by CRC.
    I hesitate to call consensus on any of this discussion
    because it's based on a version of the draft (-03) that
    is some combination of incomplete, incorrect, and/or
    difficult to comprehend in this area.  Based on this
    and the length/detail of the discussion, I suspect
    that many people on the list are not completely aware
    of the issues here, and calling consensus when a large
    segment of the WG may not understand the issues is
    unlikely to be productive.
    
    The next version of the draft (-04) SHOULD contain a
    much better section on error recovery with explanations
    and examples that make it significantly easier to
    understand.  Consensus calls on error recovery will not
    be made before it appears.
    
    Meanwhile, a few comments on ongoing issues:
    - If a CRC error occurs, trying to use any data covered
    	by that CRC is generally not a good idea in the
    	absence of other measures (e.g., an error-correcting
    	code covering the field(s) of interest).
    - Given some of the CRC discussion, I think the conclusion
    	in Orlando to have separate header and data CRCs is
    	NOT the rough consensus of the WG.  We need to go
    	back to a requirements discussion on this rather than
    	debating exactly where to put the CRCs.  Would those
    	envisioning middleboxes/gateways/etc. that would
    	benefit from this sort of CRC separation please post
    	short use cases/descriptions indicating the basic
    	functionality of the box and which fields it needs
    	to change (let's do this with reference to the header
    	layout in -03 rather than subsequent changes)?  As
    	part of the use case/description, please explain
    	how/why Fibre Channel's single CRC covering both
    	the frame header and data causes problems/difficulties.
    - Mandating the use of IPsec or TLS solely to handle
    	CRC-level integrity issues is overkill.
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    


Home

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