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

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: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of
wrstuden@wasabisystems.com
Sent: Thursday, January 29, 2004 2:46 PM
To: Mallikarjun C.
Cc: ips@ietf.org
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
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

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