SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI : Reject PDU Concerns.


    • To: IPS Reflector <ips@ece.cmu.edu>
    • Subject: iSCSI : Reject PDU Concerns.
    • From: Santosh Rao <santoshr@cup.hp.com>
    • Date: Thu, 18 Jan 2001 13:53:38 -0800
    • Content-Type: multipart/mixed;boundary="------------A167566E1CA72F4356C7B9A5"
    • Organization: Hewlett Packard, Cupertino.
    • Sender: owner-ips@ece.cmu.edu

    Ref : Section 2.19 (Reject PDU), Section 5.5 (Digest Errors)
    
    Issue :
    =====
    1) Reject PDU must return an Initiator Task Tag in the Reject PDU
    header, which provides the initiator sufficient context to lookup the
    outbound exchange that was transmitted.
    
    2) An error_byte field should be considered for inclusion in the Reject
    PDU which contains the byte offset of the errant byte[or word] in the
    received header/payload that caused the target to send a Reject response
    to the command.
    
    This is a simple solution that provides for quick fault isolation and
    root cause of the reason for the reject. This also rids the Reject PDU
    of any detailed elaboration of reason codes meant to allow root cause of
    the reason for the reject.
    
    3) The Reject PDU should only be used for " Format Error" since the
    Reject mechanism  is a per-task error recovery to deal with header
    format problems.
    "Digest Error" handling is too complex dealing with too many situations.
    Digest error recovery should be simplified to a connection level error
    recovery which involves Logout or connection close/re-start.
    
    The current digest recovery is a ping-pong as follows :
    - Target sends REJECT
    - Initiator on seeing REJECT with "Digest Error" sends Logout
    - Target sends Logout response.
    (the spec is not clear on who drives the connection close. does the
    initiator close the connection on receiving logout response, or does the
    target close connection and send logout reponse on another connection
    ??).
    
    The above procedure is quite convoluted and the followinf simplification
    should be considered :
    - On a digest error, target sends Logout, indicating appropriate reason
    code.
    - Target follows up the Logout with a TCP connection close.
    
    4) There is no value add in expecting a logout response on a logout
    which is intended to close a connection and is sent on the same
    connection. The logout can be followed up with a connection close.
    
    Regards,
    Santosh
    
    
    
    
    
    begin:vcard 
    n:Rao;Santosh 
    tel;work:408-447-3751
    x-mozilla-html:FALSE
    org:Hewlett Packard, Cupertino.;SISL
    adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
    version:2.1
    email;internet:santoshr@cup.hp.com
    title:Software Design Engineer
    x-mozilla-cpt:;21088
    fn:Santosh Rao
    end:vcard
    


Home

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