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

["Ramesh Mangamuri" <[e-mail]>]

To be honest I really don't know about the resources we would be saving
by combining R2TSN and DataSN into one variable in the of bidirectional
. But from logical standpoint, Pat's suggestion makes perfect sense to
me.

More later ...,
Rams

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Monday, February 02, 2004 9:52 AM
To: [e-mail]
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

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