SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI/iWARP drafts and flow control



    As I indicated to Caitlin in an earlier e-mail, since each iSCSI 
    control-type PDU from the target to the initiator is associated with a 
    StatSN, the ExpStatSN from the initiator can be used to advance the 
    "credit" at the target.
    
    The question is for iSCSI control-type PDUs from the initiator to the 
    target, what is the mechanism for the target to advance the "credit" at 
    the initiator?  For PDUs where the Immediate flag is not set, the CmdSN 
    and MaxCmdSN mechanism in iSCSI are already available and the new "credit" 
    scheme is not necessary.  The unsolicited SCSI Data-out PDUs are covered 
    by FirstBurstLength and again the new "credit" scheme is not needed.  The 
    "credit" scheme is needed for PDUs where the Immediate flag is set or the 
    SNACK Request (note that SNACKs are not needed in iSER).  For these PDUs, 
    the target may not be able to advance the "credit" at the initiator 
    individually.  One possibility is to wait for the initiator to issue an 
    iSCSI control-type PDU with a new CmdSN but without the Immediate flag, 
    and if the target responds with an iSCSI control-type PDU with ExpCmdSN 
    set to CmdSN + 1, then "credit" at the initiator is restored to its full 
    negotiated (or by definition) value. 
    
    As Caitlin pointed out, since no one has yet identified a specific need 
    for per-session negotiation of these credits, a simple rule enumerated in 
    the draft may be sufficient. 
    
    Mike Ko
    IBM Almaden Research
    mako@almaden.ibm.com
    
    To:     wrstuden@wasabisystems.com
    cc:     Mike Ko <mako@almaden.ibm.com>, ips@ece.cmu.edu, rddp@ietf.org 
    Subject:        Re: iSCSI/iWARP drafts and flow control
    
    
    
    
    On Friday, August 15, 2003, at 04:12 PM, wrstuden@wasabisystems.com
    wrote:
    
    > Sorry for my delay in responding.
    >
    > One of the things I've been wondering through this whole thread is
    > can't
    > we expand iSCSI negotiation to handle these parameters (like how many
    > async messages are ok, how many immediate commands, etc.)? That way, to
    > the extent that iSCSI/iWARP needs new parameters, we can decide on them
    > out easily.
    >
    > Maybe it's been in everyone's thoughts, but the thread had been talking
    > about needing new limits and talking like it's hard to do. Can't we
    > just
    > negotiate them?
    >
    > Take care,
    >
    > Bill
    
    Bill,
    
    There are two separate issues.
    
    The first is establishing what the credit limits are. That could
    be negotiated on a per session basis, or it could be established
    by the draft as a simple rule. You are correct that negotiating
    is not terribly complex. Therefore, if there is *any* benefit to
    varying those limits on a per-session basis, then negotiations
    should be allowed.
    
    So far, however, I do not believe that anyone has identified
    a specific need for per-session negotiation of these credits.
    
    The second issue is the mechanism by which credits are replenished.
    The iSER draft authors were opposed to creation of additional
    messages to exchange credits. My contention is that under virtually
    all circumstances, credit replenishment can be inferred from
    existing message exchanges. Under worst case circumstances a
    "NOP" might have to be sent that would not have otherwise
    been required. No additional message types are required.
    
    I believe the last few prior exchanges may have established
    that tracking credits is not as onerous as the draft authors
    had originally thought. But it is on that issue, not the
    overhead of negotiation during setup, that was their concern.
    
    
    
    
    
    Caitlin Bestler - cait@asomi.com - http://asomi.com/
    
    
    
    


Home

Last updated: Fri Aug 15 23:19:24 2003
12822 messages in chronological order