|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - positive data ack - change proposalRod, 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 14:17:19 2001 6723 messages in chronological order |