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

From: [email-masked]
Date: Mon, 2 Feb 2004 11:43:21 -0700

Ken,

Good point. I had missed that the DataIn and R2T are one SNACK type. Changing that would affect current implementations even if they don't do bidirectional. While I don't like the one variable, two names thing, changing it isn't worth that turmoil.

Given that, I think we need to keep target DataSN and R2TSN as one sequence for bidirectional.

There is another way to clean things up which is editorially significantly more radical but which should be less tramatic for implementations.

DataSN (for DataIn PDUs) and R2TSN are really two names for one counter variable - 
Write only commands use the counter for R2T PDUs and call it R2TSN
Read only commands use the counter for DataIn PDUs and call it DataInSN
Bidirectional commands use the counter for both kinds of PDUs and both names are applied to it depending on the PDU type.

The obvious way to clean this up is to give the SNs generated for DataIn and R2T PDUs a single name such as:
DataR2TSN
DRSN
or even just the current DataSN 
The justification for DataSN is that both R2T and DataIn are concerned with the movement of data. (See also iSER which classifies both PDUs as iSCSI data type PDUs.) Keeping this name  would minimize the amount of editorial change.

I know this editorial change would have to be carefully made (there are 35 instances of R2TSN in the draft most of which would be pretty straight forward to convert), but in the long run that is probably significantly less effort than we will expend explaining to people that DataSN and R2TSN form one sequence.

Regards,
Pat

-----Original Message-----
From: Ken Sandars [mailto:[email-masked]]
Sent: Monday, February 02, 2004 10:12 AM
To: THALER,PAT (A-Roseville,ex1); [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands

Hi Pat,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 02 February 2004 18:02
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for 
> bidirectional commands
> 
> 
> I don't think "(read)" should be in there. We don't usually 
> put read after Data-In. Also, I would rather have it a 
> separate sentence. 
> 
> For read commands, the number of Data-In PDUs the target has 
> sent for the command. For bidirectional commands, the number 
> of Data-In PDUs and R2T PDUs the target has sent for the command.
> 
> or 
> 
> For bidirectional commands, the number of Data-In PDUs and 
> R2T PDUs the target has sent for the command. For all other 
> commands, the number of Data-In PDUs the target has sent for 
> the command.
> 
> The more I think about it, the more I lean toward leaving 
> 10.4.8 as it is and changing 3.2.2 to disentangle DataSN from 
> R2TSN. Is it really worth these gymnastics to reduce 
> bidirectional command context by one variable?
> 

This would affect Data/R2T SNACK processing, but that's probably
a good thing. Perhaps explicit Data SNACK and R2T SNACK types are
All that is needed. But is this needed, or just a can-o-worms?

Cheers,
Ken Sandars
Elipsan UK

> -----Original Message-----
> From: Ramesh Mangamuri [mailto:[email-masked]]
> Sent: Saturday, January 31, 2004 1:27 PM
> To: Ken Sandars; Julian Satran; Mallikarjun C.
> Cc: THALER,PAT (A-Roseville,ex1); [email-masked]
> Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for 
> bidirectional commands
> 
> 
> Hello Ken/Julian:
> 
> I have another proposal here for section 10.4.8:
> 
> Suggestion ---------------------------
> 
> 10.4.8  ExpDataSN
> 
>    The number of Data-In (read) PDUs (for bidirectional 
> commands this is R2Ts + Data-Ins) the target has sent for the command.
> 
>    This field is reserved if the response code is not Command 
> Completed
>    at Target, or the command is Write only command.
> 
> 
> How does this sound???
> 
> -Rams
>    
> 	
> 
> 
> -----Original Message-----
> From: Ken Sandars [mailto:[email-masked]] 
> Sent: Friday, January 30, 2004 12:57 PM
> To: 'Julian Satran'; 'Mallikarjun C.'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for 
> bidirectional commands
> 
> Hi Julo,
> 
> As requested, two alternative proposals for section 10.4.8:
> 
> Suggestion 1 --------------------------
> 
> 10.4.8  ExpDataSN
> 
>    The number of R2T and Data-In (read) PDUs the target has 
> sent for the
>    command.
> 
>    This field is reserved if the response code is not Command 
> Completed
>    at Target.
> 
> 
> Suggestion 2 --------------------------
> 
> 10.4.8  ExpDataSN
> 
>    The number of R2T and Data-In (read) PDUs the target has 
> sent for the
>    command.
> 
>    This field is reserved if the response code is not Command 
> Completed
>    at Target or the target sent no Data-In PDUs for the command.
> 
> ----------------------------------------
> 
> 
> I'm more than happy with any answer which clarifies when the 
> field is reserved.
> 
> 
> Thanks,
> Ken Sandars
> Elipsan UK
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Mallikarjun C.
> > Sent: 30 January 2004 20:29
> > To: Ken Sandars
> > Cc: 'Julian Satran'; [email-masked]; [email-masked]
> > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for 
> > bidirectional commands
> > 
> > 
> > Ken,
> > 
> > I am not sure we need to restrict the wording
> > to commands with at least one Data-In PDU.  Do
> > you see an issue?
> > 
> > In any case, if you have a specific wording suggestion, 
> please send it 
> > to Julian directly (he owns the pen).
> > 
> > Regards.
> > 
> > Mallikarjun
> > 
> > 
> > 
> > Ken Sandars wrote:
> > 
> > > Hi Mallikarjun,
> > > 
> > > One final clarification request, and  I can sleep easy on
> > this topic!
> > > 
> > > Will the new wording for 10.4.8 be more general to indicate that
> > > ExpDataSN is the number of DataIn and R2T PDUs that were sent?
> > > 
> > > Is this field only valid for commands which have at least
> > one Data-In
> > > PDU?
> > > 
> > > 
> > > Thanks again,
> > > Ken Sandars
> > > Elipsan UK
> > > 
> > 
> > 
> > _______________________________________________
> > Ips mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ips
> > 
> > 
> 
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 
> 

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

---

From: [email-masked]
Date: Mon, 2 Feb 2004 12:45:39 -0800 (PST)

> Good point. I had missed that the DataIn and R2T are one SNACK type.
> Changing that would affect current implementations even if they don't do
> bidirectional. While I don't like the one variable, two names thing,
> changing it isn't worth that turmoil.
>

Not necessarily. We could add a new SNACK type for BiDi commands, say for
R2Ts for a BiDi. If we make the new type used only for BiDi commands, we
do not impact implementations that do not handle BiDi commands (for which
there is no such ambiguity).

This would, though, impact existing implementations that do support BiDi
commands. I'm not sure if we want to be that tramatic.

> There is another way to clean things up which is editorially
> significantly more radical but which should be less tramatic for
> implementations.

This option also would work.

> Bidirectional commands use the counter for both kinds of PDUs and both
> names are applied to it depending on the PDU type.
>
> The justification for DataSN is that both R2T and DataIn are concerned
> with the movement of data. (See also iSER which classifies both PDUs as
> iSCSI data type PDUs.) Keeping this name would minimize the amount of
> editorial change.
>
> I know this editorial change would have to be carefully made (there are
> 35 instances of R2TSN in the draft most of which would be pretty
> straight forward to convert), but in the long run that is probably
> significantly less effort than we will expend explaining to people that
> DataSN and R2TSN form one sequence.

Indeed. If we decide to keep it one sequence, we should do something like
this.

Take care,

Bill