SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: DAP Last Call Comments



    Howdy Julian,
    Comments to your comments below...dap
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Sunday, July 14, 2002 2:18 AM
    To: Dave Peterson
    Cc: Ips@Ece. Cmu. Edu; owner-ips@ece.cmu.edu
    Subject: Re: iSCSI: DAP Last Call Comments


    Dave - Comments in text - Thanks, Julo


    "Dave Peterson" <dap@cisco.com>
    Sent by: owner-ips@ece.cmu.edu

    07/07/2002 11:19 PM
    Please respond to "Dave Peterson"

           
            To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu>
            cc:        
            Subject:        iSCSI: DAP Last Call Comments

           


    T                 p 36                 2.2.2.1 Command Numbering and Acknowledging: 7th paragraph: if not in
    this document, where is the means to request immediate delivery for a
    command?

    +++ in some API document provided by your friendly implementer - there is no iSCSI CAM (no pun intended) +++ 
     
    dap: I hope an application (client) does not have to deal with multiple ways via different vendors to request immediate delivery. Sounds like this should be added to the iSCSI HBA API so we don't have to deal with differing vendor implementations to enable/disable this feature.

    T                 p 103                 6.1.1 Usage of Retry and 6.7 SCSI Timeouts: the semantics of Retry
    remain broken rendering it useless for tape operation. SCSI level error
    detection and recovery is the preferred mechanism. Refer to previous emails
    sent via the IPS reflector regarding this matter.

    +++ Dave. The retry scheme for connection recovery implies that the other two levels are there.
    So even if I would agree with your POW (which I am not) for practical reasons the mechanisms described
    will have to stay.
    +++ 
     
    dap: again, without a standardized method for error detection (see the options I listed) to determine when the retry may be performed, the retry functionality is broke/useless/inconsistent for tape applications. This is not an implementation detail as some suggest. This must be consistent across vendor implementations for a tape application to work consistently.
       
    T                 p 128                 8.6 Considerations for State-dependent devices: last paragraph:
    don't agree with the statement that error recovery at the iSCSI level
    (specifically Retry in its current state) is advisable. Retry at the SCSI
    level is feasible and is not difficult (i.e., READ POSITION and LOCATE
    commands). This paragraph should be removed.

    +++ that is not what we repeatedly hear. I will however make a "softer" statement. +++  
     
    dap: I don't know who is feeding you this information. READ POSITION is and has been mandatory to implement for tape devices for quite a while now. Additionally I'm on the verge of making LOCATE mandatory (in reality if READ POSITION is implemented, so is LOCATE). Any backup app/application client worth anything uses READ POSITION (and LOCATE). I have a major problem with any text that suggests otherwise. The use of READ POSITION and LOCATE mitigates the need for retry (and most error recovery) at the transport level, and this is where I want to go. Retry at the application level simply must not be performed without first:
    1. determine the position of the device using READ POSTITION, then
    2. (re)position the device if neccessary, then
    3. continue
    This is not difficult, provided READ POSITION/LOCATE are supported.
     
    If the offending paragraph is indeed targeted for legacy device support, it certainly does not say that. In reality, todays inplementations use READ POSITION/LOCATE extensively and (legacy) devices that do not support these commands are very rare for this type of tape application/environment.
    I expect that a legacy tape device will be front-ended by a bridge device (i.e., I don't expect to see a native-iSCSI legacy tape device). This legacy tape device will not support the desirable functionality (such as FCP-2 error detection and recovery) thus placing a burden on a bridge device if the desired goal is to be achieved.
    Furthermore, the legacy devices will generally be of the Parallel SCSI variety, not FCP. The FCP-x tape devices I know of each support READ POSITION/LOCATE.
     
    The offending paragraph (draft 15):
    "For many of those state changing commands the execution model also assumes that the command is executed exactly once. For those commands a retry at SCSI level is not feasible or very difficult and error recovery at iSCSI level is advisable."
    must be removed.
     
    Note: The connection reassignment capability does provide use for tape applications, e.g, will hopefully keep the application running. I have no problem using the retry functionality in this context.
     
    T                 p 214                 11.11 BidiInitialR2T: this text key provides no value and needs to
    be removed. InitialR2T should be used for both uni and bidirectional
    commands. In addition, if BidiInitialR2T were to be used, it will not
    function via an iSCSI-FCP gateway.

    +++ A gateway can easily map the keys. We don't know enough to decide off-hand to remove it.

    But I am still listening.
    +++ 

     dap: There is no reason to have a different key to indicate whether or not an R2T will be used for bidi commands. InitialR2T works just fine for both. FCP uses just one parameter (i.e., write FCP_XFER_RDY disabled) for both and all is well. What more can I say, other than remove the key.
     


Home

Last updated: Tue Jul 30 10:39:12 2002
11481 messages in chronological order