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

["Mallikarjun C." <[e-mail]>]

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.
> 
> [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


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