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



    
    On Friday, August 15, 2003, at 08:04 PM, Mike Ko wrote:
    
    > 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.
    
    Agreed.
    
    >
    > 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.
    
    My proposal is to apply a "leaky bucket" algorithm. "Extra" credits are
    granted for each CmdSN credit granted, up to a maximum. Each extra
    send decrements a fixed amount from the credits. In a pinch, Nop
    commands can be used to advance the CmdSN.
    
    It allows for bursts, and the credit-scoring can be done entirely
    when sending a message that needs an "extra" credit.
    
    
    >
    > 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.
    >
    
    Well, their negotiated credits in either case. It's just whether
    they are negotiated on a per-session basis by target and
    initiator, or negotiated on a mailing list on a per-protocol
    basis. If the volume of the mailing list negotiation gets
    too high, everyone will quickly agree to the per-session
    negotiations. ;-)
    
    
    


Home

Last updated: Mon Aug 18 09:19:32 2003
12823 messages in chronological order