SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI - Change proposal Removing the X bit



    
    Julian
    
    When would the initiator decide to issue the cleaning NOP ?
    Would this be done on a sequence wraparound ?  
    My one concern is that this puts the onus of doing things
    correctly on the initiator, and the target susceptible to
    initiator bugs. 
    
    Here's an alternate idea..
    
    It seems that for this scenario to occur the following 
    condition must also be valid :  
    
      A target MUST have a positive (expStatSN-statSN) for 
      connection c1 when it receives c2&c3 in a new window
      on the same connection c1 - since the status acks
      are pending in-order after the retried c2&c3.
    
    If this is correct.. then would the following condition 
    detect a connection which has gone stale ?
    
     A target MUST NOT allow a new CmdSN which is 2^31-1 greater
     than the unacknowledged status PDU for the last cmdSN sent
     on all connections.
    
    This would involve maintaining an additional counter per
    connection.  (e.g. Connection->cmdSN_of_last_unacknowledged_statSN)
    
    In other words, if connection C1 sent status PDU for (c3) which
    has not yet been acked thru expStatSN, then the target will not 
    allow a new command (Cn) which is 2^31-1 greater than c3.
    This must hold for all connections.
    
    This ensures that sequence wraparound does not cause old commands
    to reappear.  Either the connection is closed or the target
    issues a NOP-IN which flushes that connection.
    
    If this is true, there is no need to issue the cleaning NOP
    since the target ensures that stale connections dont exist.
    
    Note that currently, we have a very loose requirement Sec 2.2.2.2
      "A large difference between StatSN and ExpStatSN may 
       indicate a failed connection."
    
    If we can strengthen this condition, we can ensure that the target
    as well as the initiator detect the sequence wrap-around without
    relying on one end too much.
    
    Comments ?
    
    -Sandeep
    
    Julian Satran wrote:
    > 
    > Dear colleagues,
    > 
    > We intend to publish very soon version 09 of the draft in its current
    > format (not many changes) and postpone the editorial changes (already under
    > way) for 10.
    > 
    > One of the latest change proposal involves removing the X bit.
    > 
    > The X bit has been used in several types of restart/replay but is somewhat
    > made redundant by the removal
    > of the command replay.
    > 
    > This involves removing the X bit from request byte 0 and either making it
    > reserved or "shifting left" the rest of the general-use bits (I and the
    > direction bit).
    > 
    > It also involves mandating a cleaning NOP.
    > 
    > The cleaning NOP is needed in order to "flush out" old command PDU that can
    > be left over by simple sequences like the one in the following scenario:
    > 
    > 2 connections
    > 
    > On connection 1 I->T c1,c2,c3
    > On connection 2 I->T c4,c5,c6
    > 
    > Targets receives everything and acts on commands but responses are sluggish
    > and initiators sees only an ack for
    > c1.  It then retransmits c2, and c3 while there answer are in flight back
    > after which the connection is almost dead and not used by initiator.
    > 
    > After a complete wrap around, involving only connection 2,  the target
    > suddenly gets c2, c3 in a correct window and acts on them.
    > 
    > The need to clean-up old PDUs is common to all protocols that use a
    > sequence that wraps and we suggested cleaning up using a NOP.  We will
    > mandate a cleaning NOP only on connections that had at least one "retry".
    > 
    > It looks like we might e able also to abandon the task management -
    > reassign function and do it with a reissue (with the same NOP cleanout
    > implication) since retiring the replay function makes the reassign
    > unambiguous (reissuing a command, after logout, on a new connection -
    > implies reassign).
    > 
    > Please comment - I need your input urgently.
    > 
    > Julo
    


Home

Last updated: Fri Oct 26 20:17:29 2001
7415 messages in chronological order