SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: Reject reason codes



    Julian,
    
    The following Reject reason codes are defined in 
    rev07 that are related to retry -
    
    4 - Command-Retry Reject
    6 - Command-in-progress
    7 - Command Replay Not Supported
    9 - Immediate Command Retry Reject - task not found
    
    Since what we generically refer to as "retry" 
    can be (section 7.1) one of 
    	(a) command plugging, or
    	(b) command failover, or
    	(c) command replay,
    I suggest that we define the Reject codes to 
    specifically identify each of these three usages of 
    retry bit.  With that said, I propose to -
    
       - define a new reason code "Command failover not
         supported" specifically for (b). (see NOTE below)
    
       - drop "Command-Retry Reject" since it is too
         generic and can be inadvertently used for all 
         flavors of retry rejects (which have separate
         codes, but are all technically retries).
    
       - drop "Immediate Command Retry Reject" since it
         could use 
    	o "Command-in-progress" for "proactive" retries
              (since command plugging is not really valid for an 
              immediate command as it doesn't consume a CmdSN).
            o "Command failover not supported" for (b)
            o "Command Replay Not Supported" for (c)
    
         I am not sure about the current "task not found"
         qualifier - I assume that if the task is not found,
         it would be treated as a new immediate command and
         appropriately dealt with (reject-"too many immediate 
         commands"/execute).
    
    
    NOTE: I also propose that a target that does not support command 
    failover (CommandFailoverSupport=no) should fail the Logout Command
    with reason code "2" (recovery), with a TBD Logout Response
    code meaning "Connection recovery not supported.".  
    
    Once this is done, the "Command failover not supported" Reject 
    reason code (that I am proposing) is useful only for a 
    transient period while the tasks are in the process of being
    cleaned up on target - though one could arguably use "Protocol
    Error" for those cases.  My preference is to define the new
    Reject reason code for uniformity.
    --
    Mallikarjun 
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668	Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    


Home

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