SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Iterating long text responses



    I think that both 4 and 5 involve in fact some state to be kept at the
    target between PDUs sent in something related to
    to a "task control block" if we assume that all the text commands carry the
    same ITT.
    4 enables the initiator to reuse its parse buffer while 5 requires the
    initiator to allocate a buffer for all the text responses (or keep the pipe
    closed).
    4 is simpler than 5.  If you add to 4 a handle that the initiator has to
    give back the target next time (the bookmark)
    then the target does not have to keep state.
    A 0 bookmark says start from the top.  It is very much like an offset (that
    was mentioned) but it is generic and opaque.
    
    Regards,
    Julo
    
    Mark Bakke <mbakke@cisco.com> on 29-06-2001 23:18:20
    
    Please respond to Mark Bakke <mbakke@cisco.com>
    
    To:   IPS <ips@ece.cmu.edu>
    cc:
    Subject:  iSCSI: Iterating long text responses
    
    
    
    
    
    Initiator developers-
    
       Please respond to the questions at the end.
    
    Thanks,
    
    Mark
    
    
    
    The current iSCSI draft allows text command and response
    PDUs of up to 4096 bytes.  While we don't see any real
    problems for the command PDU size, commands such as SendTargets
    can easily exceed the response size.
    
    There are several ways we can fix this.  The first two solutions
    require no differences in the current iSCSI text command and
    response; the latter three involve the use of the F bit.
    
    1. Assume that such commands are done on a "special" connection
       or are handled completely in software, and allow its response
       PDU to be as large as it needs to be.
    
       This one appears too restrictive to be a solid solution.  It
       will also weaken any data digests done on the longer PDU.
    
    2. Create an iterative SendTargets key (and do the same for any
       other text commands that need this), that would allow the
       initiator to request the "next target" or "next address".
    
       This would work, but would require any new command that needed
       a large response to implement an iterator.  It also means that
       each part of the response from the iterator would have to fit
       in the 4k PDU.
    
    The remainder of these require that only one text command sequence
    be outstanding on a connection at a given time.  They use the F
    bit to indicate the last PDU of the sequence.  Note that connection
    allegiance is assumed for the entire sequence, and text commands
    are never retried on another connection; a new command is issued
    instead.
    
    3. Do a text-response R2T, where the initiator controls when the
       next partial response is sent.  This would be more generic:
    
       I->T  Text Command (F bit set)
       T->I  Text Response (first PDU, F bit cleared)
       I->T  Text Command (with some indicator that we want more)
       T->I  Text Response (next PDU, F bit cleared)
    
       ...
    
       I->T  Text Command (with indicator that we want more)
       T->I  Text Response (last PDU, F bit set)
    
       The main problem with this is that the target must keep track
       of the state of its responses; if the initiator just stops asking,
       it may have to keep a buffered response around until it times out,
       the connection is dropped, or another text command comes along.
    
    4. Allow multiple response PDUs to a single text command:
    
       I->T  Text Command (F bit set)
       T->I  Text Response (first PDU, F bit cleared)
       T->I  Text Response (next PDU, F bit cleared)
    
       ...
    
       T->I  Text Response (last PDU, F bit set)
    
       Basically, we are doing (3) without the R2T.  The initiator,
       upon sending the text command, must be prepared either to
       accept as many PDUs as come back, or throw them away if it
       can't handle them.  This solution is a lot like #1, but with
       the response spread across 4k PDUs.
    
       Also note that this (and the following scheme) avoid the problem
       of the target keeping state; it sends ALL of the response PDUs
       without the initiator asking for them.
    
    5. Do #4, but allow the initiator to specify the amount of data
       it is willing to accept:
    
       I->T  Text Command (F bit set, AcceptResponseLength=4096)
       T->I  Text Response (first PDU, F bit set, TotalResponseLength=12288)
    
       In the above example, we have created a new text command field:
    
          AcceptResponseLength
    
       And in the text response PDU:
    
          TotalResponseLength
    
       The initiator indicated it was willing to accept a 4k response.
       The target returned the first 4k in the text response, but set
       the F bit since it was at its limit.  It also returned a
       TotalResponseLength field.  Since this was greater than the
       AcceptResponseLength, the initiator knows the amount of buffer
       space it will need to get the full response.  It can then choose
       whether it will re-send the command, and if so, can give it a
       large enough response length:
    
       I->T  Text Command (F bit set, AcceptResponseLength=12288)
       T->I  Text Response (first PDU, F bit clear)
       T->I  Text Response (next PDU, F bit clear)
       T->I  Text Response (last PDU, F bit set, TotalResponseLength=12288)
    
       Note that most initiators will probably send an AcceptResponseLength
       of the largest response they would normally accept, and that most
       target responses will fit in one or a few PDUs anyway.
    
       #5 is really a compromise between #3 and #4; the target has the
       benefit of being less statefull, and the initiator has the benefit
       of controlling the amount of data it receives.
    
    I would like to recommend either #4 or #5.  I think that #5 is
    probably the safest solution, but #4 may not be a problem for anyone.
    
    Assuming that none of the implementors of initiators have a problem
    with #4, I would pick that.
    
    If they do have a problem with it, we should go with #5.
    
    Targets probably don't care much whether we do #4 or #5.
    
    
    Initiator developers-
    
      Please indicate which solution (#4 or #5) appeals to you.
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

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