Return-Path: Received: from newbox.ece.cmu.edu (localhost [127.0.0.1]) by newbox.ece.cmu.edu (Cyrus v2.1.12) with LMTP; Fri, 08 Aug 2003 11:01:10 -0400 X-Sieve: CMU Sieve 2.2 Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by newbox.ece.cmu.edu (Postfix) with ESMTP id 7BA733389 for ; Fri, 8 Aug 2003 11:01:10 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id C6637A0; Fri, 8 Aug 2003 11:01:09 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by osgood.ece.cmu.edu (Postfix) with ESMTP id 1F2E86A; Fri, 8 Aug 2003 11:00:50 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id EDACF89F2; Fri, 8 Aug 2003 11:00:33 -0400 (EDT) Delivered-To: ips-outgoing@sos.ece.cmu.edu Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by sos.ece.cmu.edu (Postfix) with ESMTP id DD22589F0 for ; Fri, 8 Aug 2003 11:00:33 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix) id BEEA38D; Fri, 8 Aug 2003 11:00:33 -0400 (EDT) Delivered-To: ips-outgoing@ece.cmu.edu Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id 8F60799; Fri, 8 Aug 2003 11:00:33 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by hazard.ece.cmu.edu (Postfix) with ESMTP id 491C18D for ; Fri, 8 Aug 2003 11:00:28 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix, from userid 363) id 2B44B89F3; Fri, 8 Aug 2003 11:00:28 -0400 (EDT) X-Original-To: ips@sos.ece.cmu.edu Delivered-To: ips@sos.ece.cmu.edu Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25]) by sos.ece.cmu.edu (Postfix) with ESMTP id 52A9889F0 for ; Fri, 8 Aug 2003 11:00:26 -0400 (EDT) Received: by osgood.ece.cmu.edu (Postfix) id 5425E6E; Fri, 8 Aug 2003 11:00:25 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by osgood.ece.cmu.edu (Postfix, from userid 953) id 26AE76A; Fri, 8 Aug 2003 11:00:25 -0400 (EDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by osgood.ece.cmu.edu (Postfix) with ESMTP id 8E6C86E; Fri, 8 Aug 2003 11:00:19 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78F0IEh131368; Fri, 8 Aug 2003 11:00:18 -0400 Received: from d03nm115.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78F0I8s184768; Fri, 8 Aug 2003 09:00:18 -0600 To: Eddy Quicksall Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: checking immediate data X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: John Hufferd Message-ID: Date: Fri, 8 Aug 2003 08:00:07 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 6.0.1 [IBM]|June 10, 2003) at 08/08/2003 09:00:18, Serialize complete at 08/08/2003 09:00:18 Content-Type: multipart/alternative; boundary="=_alternative 00525BE388256D7C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_10,HTML_10_20,QUOTED_EMAIL_TEXT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This is a multipart message in MIME format. --=_alternative 00525BE388256D7C_= Content-Type: text/plain; charset="us-ascii" Eddy, I guess I do not put this trivial immediate data check in the same league as some of the other possible performance path checks. I do not think that I can be convinced that checking a "flag" that says that I can or can't accept immediate data will impact the performance path. And with that in mind, I support David's comments. . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/System Group, San Jose CA Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Alt Office: (408) 997-6136, Cell: (408) 499-9702 Internet Address: hufferd@us.ibm.com Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 08/08/2003 06:34 AM To: Black_David@emc.com, Julian_Satran@il.ibm.com cc: ips@ece.cmu.edu Subject: RE: checking immediate data First, note that I realize it is too late to change this but I just want to comment that using that rational, it would seem that the target should be checking many other things that the initiator may do wrong. Obviously, that would eventually effect performance; and this thinking is not consistent with the consensus on another thread going on here regarding checking the ITT for reuse. In general, this kind of requirement should not appear in a performance path. Eddy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, August 08, 2003 9:26 AM To: Julian_Satran@il.ibm.com; eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: checking immediate data Eddy and Julian In the current specification, the target requirement also avoids an interoperability problem if a broken initiator sends immediate data that it has no business sending - since in the absence of the requirement, target acceptance of the immediate data will be implementation-dependent, the result is an annoying "sometimes it works, sometimes it doesn't" situation. It's better to have the initiator fail the first time it tries this and get fixed, as opposed to building up an installed base where this works when it shouldn't, as that would eventually cause removal of the ImmediateData negotiation key, as targets would always have to accept immediate data to deal with broken initiators who don't know how not to send it. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, August 08, 2003 1:25 AM > To: Eddy Quicksall > Cc: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu); owner-ips@ece.cmu.edu > Subject: Re: checking immediate data > > > The reason beyond this was that a 'highly optimized target may have > prepared already the R2T. I guess that you are objecting to > the second > MUST in the sentence and I guess that except for recovery it > is a bit too > strong. For recovery however you might end up having a > different sequence > in recovery vs. original. > > Regards, > Julo > > > > Eddy Quicksall > Sent by: owner-ips@ece.cmu.edu > 07/08/2003 19:34 > > To > "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" > cc > > Subject > checking immediate data > > > > > > > Section 12.11 says: > > If ImmediateData is set to No and InitialR2T is set to Yes, then the > initiator MUST NOT send unsolicited data and the target MUST reject > unsolicited data with the corresponding response code. > > > If the initiator says ImmediateData=No and the target has the > capability > of taking immediate data BUT the initiator sends immediate > data anyway, > why should the target be responsible to make that check (as > long as it > isn't going to break the target)? > > Eddy > > --=_alternative 00525BE388256D7C_= Content-Type: text/html; charset="us-ascii"
Eddy,
I guess I do not put this trivial immediate data check in the same league as some of the other possible performance path checks.  I do not think that I can be convinced that checking a "flag" that says that I can or can't accept immediate data will impact the performance path.  And with that in mind, I support David's comments.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: hufferd@us.ibm.com


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

08/08/2003 06:34 AM

       
        To:        Black_David@emc.com, Julian_Satran@il.ibm.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: checking immediate data



First, note that I realize it is too late to change this but I just want to
comment that using that rational, it would seem that the target should be
checking many other things that the initiator may do wrong. Obviously, that
would eventually effect performance; and this thinking is not consistent
with the consensus on another thread going on here regarding checking the
ITT for reuse.

In general, this kind of requirement should not appear in a performance
path.

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, August 08, 2003 9:26 AM
To: Julian_Satran@il.ibm.com; eddy_quicksall@ivivity.com
Cc: ips@ece.cmu.edu
Subject: RE: checking immediate data

Eddy and Julian

In the current specification, the target requirement also avoids
an interoperability problem if a broken initiator sends immediate
data that it has no business sending - since in the absence of the
requirement, target acceptance of the immediate data will be
implementation-dependent, the result is an annoying "sometimes
it works, sometimes it doesn't" situation.

It's better to have the initiator fail the first time it tries this
and get fixed, as opposed to building up an installed base where this
works when it shouldn't, as that would eventually cause removal of
the ImmediateData negotiation key, as targets would always have to
accept immediate data to deal with broken initiators who don't
know how not to send it.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, August 08, 2003 1:25 AM
> To: Eddy Quicksall
> Cc: Ips@Ece.Cmu.Edu (ips@ece.cmu.edu); owner-ips@ece.cmu.edu
> Subject: Re: checking immediate data
>
>
> The reason beyond this was that a 'highly optimized target may have
> prepared already the R2T. I guess that you are objecting to
> the second
> MUST in the sentence  and I guess that except for recovery it
> is a bit too
> strong. For recovery however you might end up having a
> different sequence
> in recovery vs. original.
>
> Regards,
> Julo
>
>
>
> Eddy Quicksall <eddy_quicksall@ivivity.com>
> Sent by: owner-ips@ece.cmu.edu
> 07/08/2003 19:34
>
> To
> "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)" <ips@ece.cmu.edu>
> cc
>
> Subject
> checking immediate data
>
>
>
>
>
>
> Section 12.11 says:
>  
> If ImmediateData is set to No and InitialR2T is set to Yes, then the
> initiator MUST NOT send unsolicited data and the target MUST reject
> unsolicited data with the corresponding response code.
>  
>  
> If the initiator says ImmediateData=No and the target has the
> capability
> of taking immediate data BUT the initiator sends immediate
> data anyway,
> why should the target be responsible to make that check (as
> long as it
> isn't going to break the target)?
>  
> Eddy
>  
>


--=_alternative 00525BE388256D7C_=--