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



    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 10:17:17 2001
6717 messages in chronological order