|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - positive data ack - change proposalRod, 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 |