|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - positive data ack - change proposalJohn, I understand the difficulty with reconstructing data from the media, I personally wouldn't attempt that in a target. I was under the impression though that this was the Orlando WG consensus, forgive me if I have misremembered. - Rod -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Tuesday, September 25, 2001 9:02 PM To: Rod Harrison Cc: ips@ece.cmu.edu Subject: RE: iSCSI - positive data ack - change proposal Rod, I think having iSCSI get the data off of the physical device to respond to a resend request, may add more complexity then you are currently thinking about. That is because, it may be going back to get data that has been changed by a write that could have come in from another connection. This gets all very complicated to control. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com "Rod Harrison" <rod.harrison@windriver.com>@ece.cmu.edu on 09/25/2001 06:09:54 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu> cc: Subject: 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 18:17:19 2001 6734 messages in chronological order |