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



    Hi Rod,
    
    I agree with what you say especially with the smaller data transfers.  For
    large transfers (e.g. tape streaming) then I still think positive ACKs are
    useful and having an ACK say every 128K is not too much to ask for in terms
    of initiator processing and bandwidth.
    
    I do think that overriding the F bit is a restriction and a new bit should
    be created.  A new bit would allow target implementations to use it if they
    desired.  Overriding the F bit is open to bandwidth abuse.
    
    Cheers
    
    Matthew
    
    -----Original Message-----
    From: Rod Harrison [mailto:rod.harrison@windriver.com]
    Sent: Tuesday, September 25, 2001 12:43 PM
    To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Julian Satran';
    ips@ece.cmu.edu
    Subject: RE: iSCSI - positive data ack - change proposal
    
    
    
    	I don't believe this proposal adequately protects the target from
    resource limitations. This works fine for 1 long running read command,
    but what about a full command window of read commands each taking 50
    or even just 10 DATA-IN PDUs?
    
    	Seems to me that the target will have to be so conservative that it
    will end up setting the F bit on almost every DATA-IN, or at least
    every few. If we end up with that many data ACKs we might as well go
    along with Santosh's proposal of in-band ACKing.  Although I have to
    admit I don't see how missing DATA-IN PDUs can be detected with
    in-band ACKs since the next DataSN on a given command can't be
    predicted. I suppose we could add a previousDataSN to the DATA-IN PDU.
    I would prefer to see data ACKs dropped.
    
    	- Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
    Sent: Monday, September 24, 2001 11:39 AM
    To: 'Julian Satran'; ips@ece.cmu.edu
    Subject: RE: iSCSI - positive data ack - change proposal
    
    
    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 08:17:22 2001
6715 messages in chronological order