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

pat_thaler@agilent.com Mon, 02 February 2004 18:57 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01639 for <ips-archive@odin.ietf.org>; Mon, 2 Feb 2004 13:57:09 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjFS-0004CH-3s for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:56:42 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IugvN016132 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:56:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjFR-0004C7-Qy for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:56:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01561 for <ips-web-archive@ietf.org>; Mon, 2 Feb 2004 13:56:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjFP-0003k9-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:56:39 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjCR-0002wx-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:53:40 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anj91-00028p-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:50:03 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj92-0003IW-3h; Mon, 02 Feb 2004 13:50:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj8b-0003FQ-Lz for ips@optimus.ietf.org; Mon, 02 Feb 2004 13:49:37 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00819 for <ips@ietf.org>; Mon, 2 Feb 2004 13:49:34 -0500 (EST)
From: pat_thaler@agilent.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anj8Z-00021z-00 for ips@ietf.org; Mon, 02 Feb 2004 13:49:35 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj56-0001IS-00 for ips@ietf.org; Mon, 02 Feb 2004 13:46:02 -0500
Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1Anj2Z-0000j6-00 for ips@ietf.org; Mon, 02 Feb 2004 13:43:23 -0500
Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 11A0723E5A; Mon, 2 Feb 2004 11:43:23 -0700 (MST)
Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id DD56D14B; Mon, 2 Feb 2004 11:43:22 -0700 (MST)
Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 11:43:22 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands
Date: Mon, 02 Feb 2004 11:43:21 -0700
Message-ID: <CA56AF7C40BC6540BA471AD2CC8F305709C602@wcosmb02.cos.agilent.com>
Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands
Thread-Index: AcPpuDWYHAlXJ9LnSaip6zoZPO4k/QAAFe0g
To: ksandars@elipsan.com, rmangamuri@istor.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com
Cc: ips@ietf.org
X-OriginalArrivalTime: 02 Feb 2004 18:43:22.0078 (UTC) FILETIME=[6EEEE7E0:01C3E9BC]
Content-Transfer-Encoding: quoted-printable
Sender: ips-admin@ietf.org
Errors-To: ips-admin@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Id: IP Storage <ips.ietf.org>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

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:ksandars@elipsan.com]
Sent: Monday, February 02, 2004 10:12 AM
To: THALER,PAT (A-Roseville,ex1); rmangamuri@istor.com;
Julian_Satran@il.ibm.com; cbm@rose.hp.com
Cc: ips@ietf.org
Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional
commands


Hi Pat,



> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] 
> Sent: 02 February 2004 18:02
> To: rmangamuri@istor.com; ksandars@elipsan.com; 
> Julian_Satran@il.ibm.com; cbm@rose.hp.com
> Cc: ips@ietf.org
> 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:rmangamuri@istor.com]
> Sent: Saturday, January 31, 2004 1:27 PM
> To: Ken Sandars; Julian Satran; Mallikarjun C.
> Cc: THALER,PAT (A-Roseville,ex1); ips@ietf.org
> 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:ksandars@elipsan.com] 
> Sent: Friday, January 30, 2004 12:57 PM
> To: 'Julian Satran'; 'Mallikarjun C.'
> Cc: pat_thaler@agilent.com; ips@ietf.org
> 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: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On
> > Behalf Of Mallikarjun C.
> > Sent: 30 January 2004 20:29
> > To: Ken Sandars
> > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org
> > 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
> > Ips@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ips
> > 
> > 
> 
> 
> 
> _______________________________________________
> 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