SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: [rddp] Re: iSCSI/iWARP drafts and flow control



    
    On Thursday, July 31, 2003, at 07:43 PM, Mallikarjun C. wrote:
    
    >
    >> No new wire protocol is required.
    >
    > Please explain to me how credit can be replenished
    > in the following example - without new positive flow
    > control protocol.
    >
    > An initiator sends an immediate command in an untagged
    > message to the target (and thus consumes one "fringe" credit).
    >
    > Considerations: a) CmdSN is not unique, can't be acked.
    > b) target may discard it, or may process it c) no assumptions
    > can be made based on  subsequent command processing.
    >
    > The other specific iSCSI PDU types that I listed present
    > a similar "problem" - for both directions.
    
    There are three cases:
    
    -- If there is no need to send a further untagged message
        then there is no need to reclaim the credit.
    
    -- If there is a later need to send a untagged message
        against the "main" credits, then the reply to that
        command will replenish the credits.
    
    -- Only exception: when sending an untagged message that
        requires the last "fringe credit", or when the "main"
        credits have been exhausted, a flag is set requesting
        an explicit flow control ack. Or a flag in the untagged
        message could request such a flow control ack.
    
    In general, responses to the "main" untagged messages
    replenish both "main" and "fringe" credits. This can
    be done without complex accounting, something along
    the lines of a "leaky bucket" algorithm.
    
    If you somehow exceed the "maximum" number of "fringe"
    credits without using "main" credits, you an simply
    use some form of "nop" command, or have a special
    "fringe" command to replenish "fringe" credits.
    But if such a a command is actually needed, it would
    mean that the sender is sending more "fringe" methods
    than the statistical methods would have allowed for
    in any event.
    
    Credits do not have to be run at a "as close to zero"
    basis as possible in order to qualify as flow control.
    
    You will probably object to having to send a reverse
    message "just" to ack the fringe methods. However,
    exactly such a message is being generated now at
    by TCP. If you really have a sequence of "fringe"
    / "oneway" messages, you are already generating
    a TCP segment to ack them. The only difference
    is that iSER would supply some data with that
    reverse flow TCP segment.
    
    


Home

Last updated: Tue Aug 05 12:46:08 2003
12771 messages in chronological order