SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: draft review - timers



    Section 1.2.3 Timers and timeouts says:
    
    >Initiators MUST implement the following timers:
    >
    >- T1 - Command delivery timer
    >- T2 - Status delivery timer
    >- T3 - Data delivery timer
    
    for the purpose of
    
    >Timers support recovery for gateways between an iSCSI transport
    >and an unreliable transport (e.g., FCP).
    
    with the action taken when they expire of:
    
    >At any timer expiration (timeout) the initiator must resend the
    >command or task management PDU with the restart bit set.
    
    I disagree with the logic of having these timers. If a gateway is
    translating between a reliable and an unreliable transport, it must
    also provide on it's own the recovery actions relating to that
    unreliable transport.
    
    For example, if the Status or Data delivery timer expires, the
    stated recovery is to resend the command with the restart bit set.
    However, this "restart" bit is only defined for iSCSI.  Other
    transports such as fibre channel know nothing about "restart" and
    thus this functionality is useless.
    
    Further, there is the argument:
    
    > The timers are meant to enable a gateway to FC to work stateless.
    
    The gateway to FC MUST be statefull.  Take this example:
    
    iSCSI sends a SCSI command to the gateway, and the gateway forwards
    it to FC.  Now, suppose the response gets trashed on the FC.  So the
    iSCSI initiator times out and will resend the command with the
    "restart" bit set.  Now, when then gateway receives the "restart"
    command, what is it going to do with it?  Let's say it statelessly
    retransmits the command.  There is no "restart" bit defined in FCP.
    So the effect is that the FC target will receive the command twice
    and perform the command twice.  Thus, the gateway MUST be statefull
    if the unreliable transport is to recover from errors - it must
    implement FCP2 error recovery!
    
    This is part of the "added value" of a gateway.  I do not see why
    iSCSI, which runs over a reliable transport, needs to be burdened
    with enabling unreliable transports via "stateless" gateways.
    
    -Matt Wakeley
    Agilent Technologies
    
    


Home

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