RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands

Hi Mallikarjun,

One final clarification request, and  I can sleep easy on this topic!

Will the new wording for 10.4.8 be more general to indicate that
ExpDataSN is the number of DataIn and R2T PDUs that were sent?

Is this field only valid for commands which have at least one Data-In
PDU?

Thanks again,
Ken Sandars
Elipsan UK

> -----Original Message-----
> From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On 
> Behalf Of Mallikarjun C.
> Sent: 30 January 2004 19:29
> To: Julian Satran; pat_thaler@agilent.com
> Cc: ips@ietf.org
> Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for 
> bidirectional commands
> 
> 
> Pat wrote:
> 
>  >One can correct the problem by changing 10.4.8 to say that 
> for  >bidirectional commands ExpDataSN is the number of 
> DataIn and R2T PDUs  >that were sent, then one can maintain 
> one value. One should also  >correct the example in B.3.
> 
> Agreed, both need to be done.
> -- 
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm [at] rose.hp.com
> 
> 
> 
> Julian Satran wrote:
> 
> > Will fix the example (thanks Pat and perhaps add the text you 
> > suggested).
> > For pratical purposes it should be noted that the only SCSI 
> device that 
> > plans to use bidirectional data transfers to-date has 
> different phases for 
> > input and output so that block are no mixed.
> > 
> > However I assumed always that the space is shared and that data 
> > placement
> > is unaffected by the order of PDU's . The SNACK identifies 
> unambiguously 
> > to the target what is missing and the initiator has to know 
> only that 
> > something is missing in order to start a recovery action.
> > 
> > Other than the example the spec is fine.
> > 
> > ips-admin@ietf.org wrote on 30/01/2004 03:25:58:
> > 
> > 
> >>I also don't think the current spec is clear and I think the
> >>combination of the behavior described in 10.4.8 and that 
> described in 
> >>3.2.2 is broken for bidirectional commands. The reason for 
> reporting 
> >>ExpDataSN in the SCSI Response is to allow the initiator to 
> check that
> >>it received all the Data-In PDUs associated with the command and to 
> >>send a SNACK if it didn't.
> >>
> >>For example, one could have the following in response to a
> >>bidirectional command:
> >>
> >>DataSN     PDU
> >>0   1st Data-In
> >>1   1st R2T
> >>2   2nd R2T
> >>3   2nd Data-In
> >>4   3rd Data-In
> >>5   4th Data-In
> >>6   3rd R2T
> >>
> >>If the ExpDataSN to be reported in the SCSI Response was truly the
> >>number of Data-In PDUs as 10.4.8 says, its value would be 
> 4. Note that
> >>the above is consistent with the text of 3.2.2.3 which says that 
> >>DataSN and R2TSN for bidirectional commands form one continuous 
> >>undifferentiated series but it is not consistent with the 
> example in 
> >>B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with 
> > 
> > DataSN = 0.
> > 
> >>This is broken because the initiator could not compare the value
> >>received in ExpDataSN to its copy of ExpDataSN to determine 
> whether it
> >>had gotten all the Data-In PDUs. If the behavior in 10.4.8 is 
> >>maintained, an initiator will have to keep a count of the 
> Data-In PDUs
> >>it has received for bidirectional commands in addition to 
> keeping the 
> >>ExpDataSN value. The target would also have to keep two separate 
> >>counters during processing of bidirectional commands (both named 
> >>ExpDataSN by the draft) - one of how many Data-In PDUs it 
> has sent so 
> >>it can put it in the Response and one of the value of ExpDataSN 
> >>indicating the DataSN to put in the next Data-In or R2T PDU 
> it sends 
> >>for the command.
> >>
> >>There is no reason to define the protocol such that keeping 
> two values 
> >>is necessary here. It appears that the reason to say that 
> DataSN and 
> >>R2TSN form one sequence for bidirectional commands is to allow the 
> >>command to maintain one count for DataIn and R2T PDUs rather than 
> >>having two counters. If we were willing to forgo that optimization, 
> >>then DataSN and R2TSN should have been kept separate.
> >>
> >>In any case, it is incorrect to have two variables for the same
> >>context with the same name.
> >>
> >>One can correct the problem by changing 10.4.8 to say that for
> >>bidirectional commands ExpDataSN is the number of DataIn 
> and R2T PDUs 
> >>that were sent, then one can maintain one value. One should also 
> >>correct the example in B.3.
> >>
> >>One could also correct the problem by changing 3.2.2 so that DataSN
> >>was kept separate from R2TSN in bidirectional commands. In some 
> >>senses, this would have been cleaner because it avoids having one 
> >>variable with two names but it would require more context 
> per command 
> >>and it is probably a bigger change for existing implementations.
> >>
> >>The code in E.2.2 seems ambiguous - it just says if (expDataSN does
> >>not match) but it doesn't define what is considered a 
> match. Neither 
> >>the target code nor the initiator code in E.2 seems to 
> address how the
> >>value of ExpDataSN for response PDUs and the compare to 
> response PDUs 
> >>is derived. Therefore it would be consistent with either choice.
> >>
> >>Regards,
> >>Pat
> 
> 
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips