Re: iSCSI:ExpDataSN overload

["Mallikarjun C." <cbm@rose.hp.com>]

Martins,

Sorry for the delay in getting to this...

ExpDataSN always means the expected DataSN from some entity's
perspective in some scope.  It may (as in reassign TMF), or may not
(as in write data reception) be communicated to the other entity.  I do
not consider the ExpDataSN for write data as an implementation issue,
iSCSI defines the error recovery protocol  if the ExpDataSN is not 
received.

Regarding 6.1.2, I agree that the wording can be improved - and your
suggestion is a good fit.

Regarding the last two sentences of 6.2:  the text is referring to the 
ExpDataSN of the current burst in a Data-Out sequence.

Regarding the "even when the CmdSN can be ...." wording, you are right - 
I will modify the sentence to imply what you suggested.

Thanks!
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Martins Krikis" <mkrikis@yahoo.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, March 12, 2002 3:37 PM
Subject: ExpDataSN overload


> Dear list members,
> 
> I've just noticed that ExpDataSN is used to denote
> a lot of different things (all references w.r.t.
> to draft 11):
> 
> 1) the total number of Data-In PDUs that a target
>    has sent to complete a SCSI (read-like) command
>    (2.5.1.2, 9.4.7, 6.6, E.9.2);
> 
> 2) next concecutive input DataSN number expected by
>    the initiator for the referenced command in
> previous
>    execution, used in TASK REASSIGN
>    (6.1.2, 9.5.4);
> 
> 3) internal target variable used to track the next
>    DataSN Expected from the initator or something
>    like that
>    (6.2).
> 
> Regarding use 1: this is the most widespread, and
> there is nothing to object, except perhaps that the
> name ExpDataSN doesn't convey the exact meaning---
> "TotalDataPDUs" or "NumDataPDUs" or something like
> that. Anyway, I can live with this.
> 
> Regarding use 2: the name conveys the meaning, but
> I don't like the wording of this spot in 6.1.2:
> "... for example taking advantage of ExpDataSN in 
> the iSCSI command PDU for read commands...". The
> problem is that "read commands" don't have ExpDataSN
> in the PDU, it's the "Task Management Function
> Request"
> PDUs that do. Task Management Function Request PDUs
> are, of course, "iSCSI command PDUs", but the whole
> thing makes it too easy to make the mistake of
> remembering (the ill-named) ExpDataSN field in 
> SCSI Response PDU, at which point nothing makes sense
> anymore, because that's the other meaning of
> ExpDataSN.
> I would appreciate if somebody could rephrase the
> sentence. I'll even volunteer:
> 
> "In reassigning connection allegiance for a command,
> the targets SHOULD continue the command from its
> current state. For example, when reassigning read
> commands, the targets SHOULD take advantage of the
> ExpDataSN field provided by the Task Management
> Function Request PDU (which must be set to zero
> if there was no data transfer) and bring the command
> to completion by sending (or resending) the status."
> 
> Regarding use 3: I don't understand this. The last
> two sentences of 6.2 seem to be talking about
> Data-Out PDUs, therefore uses 1 and 2 of ExpDataSN
> (that are both Data-In PDU related) don't apply
> here. I'm concluding that these sentences are 
> making some (unwelcome) assumptions about target
> implementation details (e.g., ExpDataSN in the role
> of a variable used to track the DataSN of the next
> Data-Out PDU that a target expects to receive for
> this command). If so, I would like such assumptions
> dropped and no MUSTs (and MAYs) imposed on a target
> implementation. If I'm wrong, somebody please explain
> to me what was meant here.
> 
> "Bonus" :-) problem:
> 
> While we're at 6.1.2, the start of the 3rd paragraph
> also got me thinking and browsing the draft for 
> quite a while. I don't like the "This is true even
> when the CmdSN can be reliably ascertained..."
> phrase. The problem is, I don't see how it could not
> be reliably determined for rejected PDUs. My thinking
> is that the only way to not be able to reliably
> determine CmdSN is in the case of header digest
> errors.
> But in this case, the PDU must be silently dropped,
> and not be answered with a Reject PDU. Am I wrong
> somewhere? If not, can we change the sentence I
> mentioned to something that explains that for rejected
> PDUs, the target will necessarily have a good CmdSN,
> but still must not use it"? 
> 
> Help on these issues will be much appreciated.
> 
>   Martins Krikis, Intel Corp.
> 
> Disclaimer: These opinions are mine only and
>             may not reflect those of my employer.
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/
>