Message-ID: <001201c3200f$4e530dd0$b76e030f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
Cc: "IPS MailingList" <ips@ece.cmu.edu>,
   "Andre Hedrick" <andre@pyxtechnologies.com>
References: <OF2951C7FE.566E21DB-ONC2256D2D.003E0E64-C2256D2D.003FF7CB@telaviv.ibm.com> <005d01c31fcc$0fdb3700$bfa6f40f@rose.hp.com> <1053548041.431.108.camel@subjekt.volcom.net>
Subject: Re: iSCSI: DataPDUInOrder=No Clairification
Date: Wed, 21 May 2003 20:07:37 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Nicholas,

> In the DataOut case, DataPDUInOrder=No renders any type of
> within-command recovery based purely on missing DataSNs useless. 

True if "purely" means not considering the F-bit.  Tracking the missing
DataSNs at the target can still be an optimization even in this case.

> In the DataIn case, DataPDUInOrder=No will not have an effect
> considering a Data SNACK requests retransmissions based on BegRun
> (DataSN) and RunLength (PDU Count).  If the target decides to send PDUs
> in random order in a sequence, it will be keeping enough metadata of
> [offset,DataSN] tuples to fulfill the Data SNACK request.

Correct, the key has no effect in this case.

> Also,  DataPDUInOrder=No IMHO is not orthogonal to within-command
> recovery considering different values for this parameter cause
> considerably different actions to be taken upon missing/failed PDUs.

The "considerably different" part depends on the perspective, but I agree
with you that there's some change in handling lost Data-out PDUs.  Perhaps
I overstated the independence of this key to recovery, that was more a
comment on the design intent which you seemed to be querying about.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: "IPS MailingList" <ips@ece.cmu.edu>; "Andre Hedrick" <andre@pyxtechnologies.com>
Sent: Wednesday, May 21, 2003 1:14 PM
Subject: Re: iSCSI: DataPDUInOrder=No Clairification


> Mallikarjun,
> 
> A few observations:
> 
> In the DataOut case, DataPDUInOrder=No renders any type of
> within-command recovery based purely on missing DataSNs useless. 
> Consider that the initiator may be sending PDUs with offsets in any
> random order in the sequence,  it is impossible for the target to
> determine the Offset of a missing DataSN in order to issue a Recovery
> R2T.  
> 
> In the DataIn case, DataPDUInOrder=No will not have an effect
> considering a Data SNACK requests retransmissions based on BegRun
> (DataSN) and RunLength (PDU Count).  If the target decides to send PDUs
> in random order in a sequence, it will be keeping enough metadata of
> [offset,DataSN] tuples to fulfill the Data SNACK request.
> 
> It is also assumed the initiator will be keeping the same tuple, but
> again the target has no method of requesting retransmissions based on
> DataSN. (Perhaps this should be addressed aside from a Recovery R2T in
> iSCSI v2 :-).
> 
> Also,  DataPDUInOrder=No IMHO is not orthogonal to within-command
> recovery considering different values for this parameter cause
> considerably different actions to be taken upon missing/failed PDUs.
> 
> Thanks,
> Nicholas 
> 
> On Wed, 2003-05-21 at 12:04, Mallikarjun C. wrote:
> > In addition to what Julian just said -
> > 
> > iSCSI targets may choose to process inbound Data PDUs
> > and track missing DataSNs to issue recovery R2Ts, regardless
> > of the negotiated value of the DataPDUInOrder key.  This
> > key negotiates the relationship between DataSNs and their
> > Buffer Offset values and thus is orthogonal to recovery.
> > --
> > Mallikarjun
> > 
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm@rose.hp.com
> > 
> > ----- Original Message -----
> > From: "Julian Satran" <Julian_Satran@il.ibm.com>
> > To: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
> > Cc: "Andre Hedrick" <andre@pyxtechnologies.com>; "David Black" <Black_David@emc.com>; "Mallikarjun
> > Chadalapaka" <cbm@rose.hp.com>; "IPS MailingList" <ips@ece.cmu.edu>
> > Sent: Wednesday, May 21, 2003 4:38 AM
> > Subject: Re: iSCSI: DataPDUInOrder=No Clairification
> > 
> > 
> > > Dear Nicholas,
> > >
> > >
> > > "Nicholas A. Bellinger" <nick@pyxtechnologies.com> wrote on 21/05/2003
> > > 12:48:15:
> > >
> > > > [This is a resend due to mailer problems, please excuse any duplicates.]
> > > >
> > > > Greeting all,
> > > >
> > > >    I am inquiring about the author's intent and proper usage of
> > > > DataPDUInOrder=No.  Of course the definition of the aforementioned
> > > > parameter is defined in section 12.18:
> > > >
> > > > "No is used by iSCSI to indicate that the data PDUs within sequences
> > > >  can be in any order."
> > > >
> > > > I had originally used the interpretation that it was mainly designed to
> > > > aid within-command recovery in the following DataOUT (not excluding
> > > > DataIN) example:
> > > >
> > > > When a DataOut PDU fails a Data Checksum, DataPDUInOrder=No allows the
> > > > target to continue to receive the rest of the DataOut sequence without
> > > > having to discard PDUs received after the initial failure.  Hence,
> > > > the Recovery R2T only has to contain Failed Offset + Failed PDU Length.
> > > >
> > > > This compared to the same example with DataPDUInOrder=Yes:
> > > >
> > > > When a DataOut PDU fails a Data Checksum, DataPDUInOrder=Yes requires
> > > > the target to NOT acknowledge the any futher PDUs in the DataOut
> > > > sequence until the initial failure is recovered.  Hence, the Recovery
> > > > R2T must contain Failed Offset -> Length to end of Sequence.
> > > >
> > > > This type of example seems like the most logical application of
> > > > DataPDUInOrder=No, that is one assumes the pdus in a given sequence will
> > > > be still sent in increasing order.  If an error occurs one is allowed to
> > > > continue to receieve pdus out of order and request only the missing
> > > > ones.
> > > >
> > > > Now let us consider another more unorthadox (and perhaps a bit
> > > > illogical) example:
> > > >
> > > > Consider a DataOUT Sequence of 32k, interpreting the definition in
> > > > section 12.18 can one assume the following is legal?
> > > >
> > > > Initiator -> Target
> > > >
> > > > DataSN: 0, Offset: 24576, Length: 8192
> > > > DataSN: 1, Offset: 0, Length: 8192
> > > > DataSN: 2, Offset: 16384, Length: 8192
> > > > DataSN: 3, Offset: 8192, Length: 8192
> > > >
> > > This is indeed legal
> > >
> > > > This type of example assumes the pdus in a given sequence may be sent in
> > > > any order, and the target handles the metadata for each pdu.  If this is
> > > > indeed legal, then its safe to assume the following 128k DataIN example
> > > > for DataSequenceInOrder=No is legal as well:
> > > >
> > > > Target -> Initiator
> > > >
> > > > Sequence 0: Offsets: 65536->98304
> > > > Sequence 1: Offsets: 32768->65536
> > > > Sequence 2: Offsets: 98304->131072
> > > > Sequence 3: Offsets: 0->32768
> > > >
> > > > My guess is these both are indeed legal.
> > > >
> > >
> > > Yes they are legal.
> > >
> > > The stricter sequencing requirement is not there to avoid recovery but
> > > rather to enable devices to optimize
> > > transmission in face of "mechanical" delay and lack of resources.
> > >
> > > > Thanks,
> > > > --
> > > > Nicholas A. Bellinger <nick@pyxtechnologies.com>
> > > >
> > >
> 
>