SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI - positive data ack - change proposal



    
    Rod,
    
    I have a long day and I intended to answer you but I  don't recall if I
    did.
    If I did I apologize for the duplicate.
    
    If I did not here it is:
    
    -1) The NOP just won't do it. NOP does not help detecting holes due to
    digest failures and that is the main reason target
    is keeping data buffers (if it can't recover them from the media - like
    from a tape) - to be able to ship them for SNACK.
    
    
    -2) The traffic argument is minor - as I said earlier the ACKs are no more
    or less desirable than R2T. An extremely conservative target may issue an
    R2T for every PDU. Should we be concerned? All the rest of the mechanisms
    are already there.
    
    The target will not stop transmitting data (speed will not be affected) as
    Matthew suggested.
    
    Julo
    
    
                                                                                                    
                        "Rod Harrison"                                                              
                        <rod.harrison@wind       To:     Julian Satran/Haifa/IBM@IBMIL,             
                        river.com>                <ips@ece.cmu.edu>                                 
                                                 cc:                                                
                        25-09-01 19:21           Subject:     RE: iSCSI - positive data ack -       
                        Please respond to         change proposal                                   
                        "Rod Harrison"                                                              
                                                                                                    
                                                                                                    
    
    
    
    Julian,
    
               I understand that the NOP is not actually an ACK itself.
    However,
    given the way an initiator must process a non-immediate NOP-IN ping
    request I believe it can be used to gain some understanding of when
    buffers associated with DATA-IN PDUs might be released.
    
               I don't really want to argue for using the NOP this way, I don't
    think it's a great idea. I just wanted to throw it in to show that a
    target can get most of what it needs even without a specific ACK
    mechanism.
    
               Please keep in mind this was based on the assumption that long
    transfers that might cause the target problems are rare, and so this
    use of NOP would be rare. If this is not the case then I believe an
    in-band ACK is necessary.
    
               - Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Tuesday, September 25, 2001 4:03 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI - positive data ack - change proposal
    
    
    Rod,
    
    My English is not that good Rod. What I meant to say about the NOP is
    that
    it does not convey information (it can't be used by itself as an
    ack!).
    
    I can understand that ack is seldomly needed but we can certainly
    improve
    targets (make them less expensive) by having it.
    
    I can understand also that data (for real applications) could be
    rebuilt.
    
    But you should not get the list into believing that there is a simple
    alternative.
    
    
    Julo
    
    
    
                        "Rod Harrison"
                        <rod.harrison@wind       To:     Julian
    Satran/Haifa/IBM@IBMIL,
                        river.com>                <ips@ece.cmu.edu>
                        Sent by:                 cc:
                        owner-ips@ece.cmu.       Subject:     RE: iSCSI -
    positive data ack -
                        edu                       change proposal
    
    
                        25-09-01 15:09
                        Please respond to
                        "Rod Harrison"
    
    
    
    
    
    Julian,
    
               The NOP mechanism is awkward, no question, but I wasn't
    thinking
    it
    was something we should specify and mandate. Rather it is something
    that a target might do under extreme, and hopefully unlikely
    conditions.
    
               - Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Tuesday, September 25, 2001 1:02 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI - positive data ack - change proposal
    
    
    Matthew,
    
    I can fix the text and the ack for the last - we can dispense with,
    but
    unlike we gather more support we will have to drop this.   I think
    that the
    NOP mechanism is awkward but is awkward and as the target shares the
    penalty for SNAK it has no real incentive to the F bit in every PDU.
    
    Julo
    
    
    
                        "BURBRIDGE,MATTH
                        EW                     To:     Julian
    Satran/Haifa/IBM@IBMIL,
                        (HP-UnitedKingdo        ips@ece.cmu.edu
                        m,ex2)"                cc:
                        <matthew_burbrid       Subject:     RE: iSCSI -
    positive data ack -
                        ge@hp.com>              change proposal
    
                        24-09-01 12:38
                        Please respond
                        to
                        "BURBRIDGE,MATTH
                        EW
                        (HP-UnitedKingdo
                        m,ex2)"
    
    
    
    
    
    Julian
    
    This looks good!
    
    A couple of comments:
    
    Please could you add a paragraph to state that a target does not
    necessarily
    need to wait for the acknowledgment of a sequence before starting
    transmission of the next sequence - for performance reasons.
    
    In section 3.7.1 it states that "Upon receiving an Data-In PDU with
    the F
    set to 1 in a session with ErrorRecoveryLevel 1 or higher the
    initiator
    MUST
    issue a DataACK type of SNACK indicating the next expected DataSN for
    this
    task".  Is this true for all incoming data sequences including the
    final
    sequence of the transfer?
    
    Cheers
    
    Matthew
    
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Sunday, September 23, 2001 2:46 AM
    To: ips@ece.cmu.edu
    Subject: Re: iSCSI - positive data ack - change proposal
    
    
    Here is updated version (in the previous I had excluded the sequences
    ended
    with Status with no good reason.
    
    Julo
    
    (See attached file: ack.txt)
    
    ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 -----
    
    
    
                        Julian Satran
    
                                             To:     ips@ece.cmu.edu
    
                        22-09-2001           cc:
    
                        14:04                From:   Julian
    Satran/Haifa/IBM@IBMIL
                                             Subject:     iSCSI - positive
    data
    ack - change
                                              proposal
    
    
    
    
    
    
    
    
    
    
    Dear colleagues,
    
    As  I mentioned earlier all the elements needed for positive data-ack
    are
    already in place.
    
    I am suggesting the following changes to the document to reintroduce
    the
    data-ACK.
    
    Comments?
    
    Julo
    
    **** Attachment ack.txt has been removed from this note on 23
    September
    2001 by Julian Satran ****
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 25 17:17:23 2001
6732 messages in chronological order