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

[Julian Satran <[e-mail]>]

Pat,

Regardless of the name - the two types of PDUs share the same space and if 
one is missing it has to be recovered.
The target knows exactly what each one was and the initiator asks for both 
the same way.
I don't see a point in changing something that is not broken. 

Regards,
Julo



<[e-mail]> 
02/02/2004 19:51

To
Julian Satran/Haifa/IBM@IBMIL
cc
<[e-mail]>, <[e-mail]>, <[e-mail]>, 
<[e-mail]>
Subject
RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands






If we really believe that the change would be overly painful for current 
and in development implementations, I would prefer a change to make R2TSN 
and DataSN independent for bidirectional commands. The logic:

Bidirectional commands already need extra context so carrying an extra SN 
variable is a very small burden to them.

It is poor form to have one variable that is sitting under two names. It 
creates confusion and is likely to cause interoperability problems in the 
future. 

Therefore, it is worth the burden of carrying an extra value in 
bidirectional command context to forstall interoperability problems.

Regards,
Pat

-----Original Message-----
From: Julian Satran [mailto:[e-mail]]
Sent: Friday, January 30, 2004 3:57 AM
To: THALER,PAT (A-Roseville,ex1)
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands


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.

[e-mail] 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
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: Thursday, January 29, 2004 2:46 PM
> To: Mallikarjun C.
> Cc: [e-mail]
> Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
> commands
> 
> 
> On Thu, 29 Jan 2004, Mallikarjun C. wrote:
> 
> > Not sure why the initiator needs to be reported on the
> > total # of R2Ts in the final response....I presume
> > any mismatch in R2Ts is already factored into the status.
> >
> > _If_ we indeed want to include R2Ts, I think it would be
> > necessary to make changes (10.4.8, E.2.2, and perhaps 6)
> > because I believe the current spec semantics are clear
> > that R2Ts are not included.
> 
> While I'll be honest that I don't understand _why_ R2Ts are factored 
into
> the DataSN space along with Data-In PDUs, I've understood they were
> comingled for over a year. I think it was about 16 months ago I asked
> about this (before draft 20), and Julian explained that they shared the
> same space.
> 
> So I don't think it's supposed to be something new.
> 
> Take care,
> 
> Bill
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips




_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips